Deepgram
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Connect Deepgram to PostHog to sync your data into the PostHog data warehouse for analysis and modeling.
Enter your Deepgram API key to sync your Deepgram Management API data into the PostHog Data warehouse.
You can create an API key in your Deepgram Console under Settings → API Keys. A key with a read-capable scope (e.g. member) is sufficient — the source only reads projects, members, keys, balances, invites, and the request log.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Linking Deepgram to PostHog
- Go to the Data pipeline page in PostHog
- Click New source and select Deepgram
- Fill in the required configuration fields
- Click Next, select the tables you want to sync, and then press Import
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
projects | A Deepgram project — the top-level container that owns members, API keys, balances, and requests. | Full refresh | — | project_id |
members | A user who is a member of the project, with their assigned scopes. | Full refresh | — | project_id, member_id |
keys | An API key belonging to the project. The nested key object is flattened onto the row root, alongside the member the key was created for. | Full refresh | — | project_id, api_key_id |
balances | A funding balance for the project, in the account's billing units. | Full refresh | — | project_id, balance_id |
invites | A pending invitation for a user to join the project. | Full refresh | — | project_id, email |
requests | A single inference request made against the project, with model/feature metadata, the response code, and the time it was created. Synced incrementally on | Incremental, Full refresh | created | project_id, request_id |
models | A model the project can call, public or non-public, with the identifier that request rows refer to. Speech-to-text and text-to-speech models share the table and are told apart by | Full refresh | — | project_id, uuid |
usage_breakdown | Usage totals for one period of a project, broken down by the dimensions the request grouped on. Synced incrementally on the period's start date. | Incremental, Full refresh | start | project_id, start, end, grouping_key |
billing_breakdown | What a project was billed for one period, broken down by the dimensions the request grouped on. Synced incrementally on the period's start date. | Incremental, Full refresh | start | project_id, start, end, grouping_key |
usage_fields | The models, tags, processing methods and features the project used in the period. These are the dimensions a usage breakdown can be sliced by. One row per value. | Full refresh | — | project_id, field, value |
billing_fields | The accessors, deployments, tags and line items the project was billed on in the period. These are the dimensions a billing breakdown can be sliced by. One row per value. | Full refresh | — | project_id, field, value |