> ## Documentation Index > Fetch the complete documentation index at: https://docs.rippit.com/llms.txt > Use this file to discover all available pages before exploring further. # Decagon > Technical reference for the Rippit Decagon data integration: API key authorization, API endpoints, what a conversation becomes in Rippit, voice recordings, and sync behavior. A read-only API key integration that syncs Decagon AI agent conversations into Rippit on a schedule. For what applies to every integration, see [how data integrations work](/plg/data-integrations). For the security model, see [Data integration security](/security/data-integrations). ## Connection summary | | | | - | - | | Authorization | Decagon API key, sent as `Authorization: Bearer ` | | Scope parameter | None | | Writes to Decagon | None. Every call is a `GET` | | Credentials shared with Rippit | The API key. Rippit stores it and uses it for every sync | | Credential check | The key is tested against Decagon before the connection is saved. A rejected key saves nothing | | Connection identity | The team ID you enter, or `default` when you leave it blank. It names the connection in Rippit and is not sent to Decagon | | Required Rippit role | Workspace admin | | API base | `https://api.decagon.ai` | | API version | None. No version is sent in the path or headers | | Sync method | Scheduled polling | | Voice recordings | Downloaded and stored by Rippit, for voice conversations | | Historical backfill | 7 days by default, up to 90 days | | Field selection limit | 150 columns | ## Before you connect Rippit asks for an API key and an optional team ID. Find or create the API key on the **Developer** page of your Decagon dashboard. The team ID is needed only if you connect more than one Decagon team, so each connection has its own name. It accepts letters, numbers, underscores, and hyphens. ## Data handling | Question | Answer | | - | - | | Is conversation content ingested, or only metadata? | Full content: every message, plus the conversation's summary, notes, resolution, flow type, deflection status, CSAT score, tags, and metadata | | Are voice recordings stored? | Yes. For voice conversations, the recording is downloaded and stored rather than linked | | Are voice recordings transcribed? | Yes. Rippit transcribes every stored voice recording | | Are Watchtower reviews ingested? | Yes. Each review's job name, flag, result, rationale, rubric score, and per-category choices and scores are stored with the conversation | | Can Rippit modify Decagon? | No. No write code path exists | ### What a conversation becomes in Rippit Each Decagon conversation becomes one conversation in Rippit. | Rippit record | Content | | - | - | | Subject | The conversation summary | | Agent | One agent per connection, named `Decagon AI ()`, who authors every AI message | | Customer | The conversation's user ID, with the email from the conversation's `metadata.email` when present | | Start and end | The conversation's creation time, and the time of its last message | | Fields | Flow type, resolution, deflection status, CSAT score, tags, and summary | | Default selected fields | Subject, flow type, resolution, deflection status, tags, CSAT score, commenters, first commenter, and last commenter | | Message comments | Every message, in order. User messages are attributed to the customer and AI messages to the Decagon AI agent. A message with any other role is attributed to that role's name | | Recording | For voice conversations, the call audio attached to the conversation | When you choose fields during setup, the list shows the fields above plus custom attributes from your Decagon conversations. Rippit finds them by checking the first 50 conversations updated in the last 7 days. An attribute shows in the list if at least one of those conversations has a value for it. Metadata attributes show with `metadata_` in front of the name. The sample decides what shows in the list: * An attribute used only on conversations not updated in the last 7 days, or on none of the 50 checked, does not show. * If no conversation was updated in the last 7 days, the list shows only the fields above. After setup, the list of fields you can add to the table is rebuilt at most every 6 hours from a small sample: one recent conversation, plus the oldest page of conversations from the last 30 days and the oldest page from all time. A commonly used new field usually appears within hours. A rarely used one can be missed. ## API endpoints | Object | Endpoint | Method | | - | - | - | | Credential check when you connect | `/conversation/export?max_timestamp=0` | GET | | Conversations | `/conversation/export?use_updated_at=true&min_timestamp=&max_timestamp=` | GET | | Recording URL, for voice conversations | `/conversation/recording_url/` | GET | | Recording file | The `signed_url` returned by the call above | GET | | Field discovery, the field picker | `/conversation/export?use_updated_at=true` for the last 7 days, the first 50 conversations | GET | | Field discovery, the field list Rippit stores | `/conversation/export` with no window, then with a window over the last 30 days | GET | The credential check sets an upper bound of `0`, the Unix epoch, so it always returns an empty page and reads no conversations. `/conversation/export` returns each conversation in full, with its messages, so no other endpoint is called for content. Timestamps are Unix seconds. Decagon pages with a `next_cursor` timestamp, and Rippit requests the next page by moving `min_timestamp` to it. **Recordings.** For each voice conversation, Rippit first requests a signed URL from `/conversation/recording_url/` with the API key, then downloads the file from that URL. The signed URL is requested again on each download attempt. The API key is sent only to URLs on an `api.decagon.ai` host. ## Sync behavior | | | | - | - | | Conversation discovery | Windowed on the conversation's last update (`use_updated_at=true`), cursor pagination | | Window width | 24 hours, one window at a time | | Trailing buffer | Each window closes 5 minutes behind the current time | | Daily re-sweep | Once a day the last 24 hours are listed again | | Update handling | An updated conversation is listed again and refetched in full | | Recording download | Every hour | | Expected latency | Up to 2 hours after a conversation updates | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.