> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DataStax Astra DB

> Serverless Cassandra — members & access

<Tabs>
  <Tab title="Overview">
    Connect DataStax Astra DB with an organization application token to sync organization members, databases, and token clients, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Astra **organization** — the one that was active in the Astra Portal when the token was generated. Astra's roster carries no name field, so each row shows the part of the member's email address before the `@` in place of a name, together with their email and their Astra roles (for example **Organization Administrator**, or **Member** when Astra reports none). People who have not yet accepted their invitation are left out. A member whose status Astra reports as **active** is shown as **Active**; any other status is shown as **Inactive**. Astra exposes no join date, so each row is stamped with the date of the sync. DataStax Astra DB reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Astra organization user roster — email addresses, roles and account status — which appears on your **Access** page; and your Astra **databases** and the organization's **token clients**, which appear on your **Inventory** page. Each database row carries its region, status, cloud provider, tier, database type and keyspace count; terminated databases are excluded by the query itself, while hibernated ones are still listed. Each token client row carries its description, its roles (resolved to names through the organization's role catalogue, which is read only when at least one token client exists), the date it was generated and its expiry — or **never expires** when it has none — and never the secret, which the endpoint does not return. Members' last-login times are not available in the API and are not read.

    It calls these DataStax Astra DB endpoints on `api.astra.datastax.com`:

    * `/v2/currentOrg`
    * `/v2/organizations/users`
    * `/v2/databases?include=nonterminated&limit=100`
    * `/v2/clientIdSecrets`
    * `/v2/organizations/roles`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your DataStax Astra DB environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The most common cause is a **database-scoped token**: a token generated from inside a database (the Connect or quickstart flow) carries a custom Database Administrator role limited to that database, and Astra answers the roster request with a 403. Only **Settings → Tokens** in the Astra Portal produces an organization-scoped token; generate one there with the **Organization Administrator** role and connect again. A deleted token, or a token that can see no organization, is rejected the same way.
      </Accordion>

      <Accordion title="The Access page shows the wrong organization">
        An Astra token is bound to whichever organization was active in the Astra Portal when it was generated, and DSALTA offers no organization selector. If you belong to several organizations, switch to the one you want reviewed before generating the token, then disconnect and connect again with the new token. Note that disconnecting permanently deletes the data already collected from Astra.
      </Accordion>

      <Accordion title="Inventory is empty or incomplete while Access works">
        Databases, token clients and the role catalogue are read best-effort after the member roster: a failure on one of those calls leaves that part of the Inventory page empty without failing the sync, and if only the role catalogue fails, token clients still appear with raw role IDs in place of role names. Databases appear once you have created one. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An organization-scoped Astra application token. The organization is detected automatically. Read-only.

    **Before you begin**

    * An Astra DB organization.
    * A role that can manage organization users — the **Organization Administrator** role.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Application token** | Astra Portal header → **Settings → Tokens → Generate New Token** | Shown once, at creation (`AstraCS:…`) |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **DataStax Astra DB**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the organization token settings">
        Sign in at [astra.datastax.com](https://astra.datastax.com). If you belong to several organizations, switch to the one to connect first: the token is bound to the organization active when it is created. Then open **Settings** in the header and choose **Tokens**.
      </Step>

      <Step title="Generate an Organization Administrator token">
        Under **Generate New Token**, choose the role **Organization Administrator**, then click **Generate Token**.

        <Warning>
          **Do not use a token generated from inside a database.** The Connect and quickstart flows produce database-scoped tokens that cannot list users, and DSALTA rejects them at connect time. Only a token from **Settings → Tokens** is organization-scoped.
        </Warning>
      </Step>

      <Step title="Copy the token and connect">
        Copy the token starting with `AstraCS:` — the Astra Portal shows it once; if you lose it, generate a new one and delete the old one. Return to the connect panel, paste it, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the organization the token belongs to and then listing that organization's users with it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or deleted token, a database-scoped token instead of an organization-scoped one with the Organization Administrator role, or a token that can see no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/datastax-astra/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with DataStax Astra DB access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/datastax-astra/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active DataStax Astra DB access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage application tokens](https://docs.datastax.com/en/astra-db-serverless/administration/manage-application-tokens.html) |
    | Remediation | [Manage users](https://docs.datastax.com/en/astra-db-serverless/administration/manage-users.html) |
    | General | [Astra Portal](https://astra.datastax.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>