> ## 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.

# Deepgram

> Voice AI platform — members, API keys & access

<Tabs>
  <Tab title="Overview">
    Connect Deepgram with an Admin-role API key to sync project members with their roles, projects and API keys, 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 every Deepgram **project** the key can see, combined into one roster: a person who is a member of several projects appears once, with the scopes Deepgram reports for them joined in the role column (for example **Owner**, **Admin** or **Member**, or **Member** when Deepgram reports none). Each row shows the member's first and last name, or their email address when Deepgram carries no name. Pending invitations are not members and are not read, and API keys belong to members rather than appearing as accounts of their own. Deepgram reports no membership status or join date, so every row is shown as **Active** and stamped with the date of the sync. Deepgram 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 project member rosters — names, emails and scopes — which appear on your **Access** page; and your Deepgram **projects** and the **API keys** in each project (the key's name, its scopes, when it was created, when it expires or *never*, the project it belongs to and the email of the member who owns it — never the secret), which appear on your **Inventory** page. API keys are read best-effort per project after the roster. Members' sign-in method, project invitations, models, agents, usage, balances and requests are not read.

    It calls these Deepgram endpoints on `api.deepgram.com`:

    * `/v1/projects`
    * `/v1/projects/{project_id}/members`
    * `/v1/projects/{project_id}/keys`

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

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key was created without opening **Advanced** and choosing the **Admin** role. Such a key authenticates and lists projects but cannot read a project's members, and DSALTA checks the members call at connect time, so it is rejected with an Admin-role remedy rather than connecting with an empty Access page. Create the key again in **Settings → API Keys**, click **Advanced**, set the role to **Admin**, and connect again. An invalid or deleted key is rejected too, with a hint to check the key.
      </Accordion>

      <Accordion title="The connection stopped working">
        A key created with an expiration date stops working when it lapses. Create a new key with **Expiration** set to *never expire*, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Deepgram.
      </Accordion>

      <Accordion title="Inventory shows the project but no API keys">
        API keys are read best-effort per project after the member roster: a failure on that call leaves the keys off the Inventory page without failing the sync. 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">
    A Deepgram API key created with the Admin role. Projects are detected automatically. Read-only.

    **Before you begin**

    * A Deepgram project Owner or Admin — only those roles can create an Admin-role key.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key (Admin role)** | Projects dropdown → the project → **Settings → API Keys → Create a New API Key**, then **Advanced → Admin** | Shown once |

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

      <Step title="Open the project's API keys">
        In the [Deepgram Console](https://console.deepgram.com), pick the project to review from the **Projects** dropdown (top left), then open **Settings → API Keys** and click **Create a New API Key**. Keys are created inside a project, so create it in the project whose roster you want reviewed.
      </Step>

      <Step title="Create the key with the Admin role">
        Give the key a name, click **Advanced** and set the role to **Admin**. Set **Expiration** to *never expire*, click **Create Key** and copy the secret.

        <Info>
          **Advanced → Admin is the step that decides whether the connection works.** A key created with the default role authenticates and lists projects but cannot read the project's members, and DSALTA rejects it when you click **Connect**.
        </Info>

        <Warning>
          The secret is shown once — Deepgram warns that it will not be able to show you the key again. If you lose it, create a new key.
        </Warning>
      </Step>

      <Step title="Connect Deepgram">
        Return to the connect panel, paste the API key, and click **Connect**. Projects are detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the projects the key can see and reading the members of every one of them. A key that sees no project, or that cannot read a project's members, is rejected. 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 expired key, a key created without the **Admin** role under **Advanced**, or a key that can see no project.

      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/deepgram/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Deepgram access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/deepgram/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Deepgram access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create additional API keys](https://developers.deepgram.com/docs/create-additional-api-keys) |
    | Remediation | [Managing projects](https://developers.deepgram.com/docs/managing-projects) |
    | General | [Deepgram Console](https://console.deepgram.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>