Linking Gladly as a source
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.
Contents
This source is currently in alpha. The interface and available tables may change.
The Gladly connector pulls your customer service data into the PostHog data warehouse: customers, conversation items, agents, and topics, plus conversations and the lifecycle events behind them.
Adding a data source
- Go to the sources tab of the data pipeline section in PostHog.
- Click + New source and then click Link next to Gladly.
- In Gladly, go to Settings > API Tokens and create an API token for an agent with the API User permission. Note the agent's email address and the generated token.
- Back in PostHog, enter your Organization, the Agent email, and the API token. Your organization is the part of your Gladly URL before
.gladly.com– formyorg.gladly.comentermyorg, and formyorg.us-1.gladly.comentermyorg.us-1. - Leave Gladly domain on Production (gladly.com) unless you are connecting a Gladly sandbox, which is served on
gladly.qa. Click Next. - Select the tables you want to sync, set the sync method and frequency, then click Import.
Once the syncs are complete, you can start using Gladly data in PostHog.
Configuration
| Option | Type | Required |
|---|---|---|
Organization | text | Yes |
Agent email | Yes | |
API token | password | Yes |
Gladly domain | select | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
customers | A customer profile in Gladly, with contact details and custom attributes. | Incremental, Full refresh | _job_updated_at | — |
conversation_items | An item within a customer conversation — a message, call, chat, or status change. | Incremental, Full refresh | _job_updated_at | — |
agents | An agent (staff user) in the Gladly workspace. | Incremental, Full refresh | _job_updated_at | — |
topics | A topic used to categorize and tag conversations in Gladly. | Incremental, Full refresh | _job_updated_at | — |
conversations | A customer conversation, with its current status, assignment, and lifecycle timestamps. One row per conversation, from Gladly's Conversation Export report. | Incremental, Full refresh | created_at | — |
conversation_timestamps | A conversation lifecycle event (created, closed, reopened, topic change, assignee change, note, merge). One row per event, from Gladly's Conversation Timestamps report. | Incremental, Full refresh | timestamp | — |
contact_timestamps | A contact lifecycle event (started, offered, transferred, held, fulfilled, ended) across channels. One row per event, from Gladly's Contact Timestamps report. | Incremental, Full refresh | timestamp | — |
Gladly has no traditional REST API for bulk data, so these tables come from two different places, and each place has its own limits on how far back you can go.
Export job tables
customers, conversation_items, agents, and topics come from Gladly's scheduled export jobs. Gladly produces JSONL files on an hourly or daily schedule, and PostHog processes them oldest first.
Each row carries _job_id and _job_updated_at columns injected from the export job that produced it. _job_updated_at is the incremental cursor.
Gladly retains export job files for 14 days. The first sync imports everything within that window. To get history older than 14 days, ask Gladly support to regenerate the past exports.
Report tables
conversations, conversation_timestamps, and contact_timestamps come from Gladly's reports instead, so the 14-day export window does not limit them. PostHog requests the reports one time window at a time, oldest window first.
conversationsholds one row per conversation and backfills two years of history.conversation_timestampsandcontact_timestampshold one row per lifecycle event and backfill 90 days. Both are high volume, so they are unselected by default.
A conversation report row restates in place as the conversation changes – when it closes, for example, or changes assignee. Each incremental sync of conversations therefore re-reads a trailing 30 days to pick up those changes. Rows older than that only refresh on a full refresh.
Gladly limits the reports endpoint to 10 requests per minute, so PostHog paces its requests to stay under that. A large backfill takes a while as a result.
Gladly also caps a single report at roughly 100,000 rows and truncates anything past it without saying so. PostHog sizes its report windows to stay clear of that cap, and logs a warning if a window gets close.
The report tables merge on their primary key and cannot run as append only, because PostHog re-reads a report window whenever a sync resumes.
Troubleshooting
- "Gladly denied access. Please check that the agent has the API User permission": the token authenticated, but its agent cannot read the API. Give the agent the API User permission under Settings > API Tokens in Gladly.
- "Gladly authentication failed": the agent email or the API token is wrong. Check both, and confirm the token belongs to the agent whose email you entered.
- "Gladly returned a report without the columns this table syncs on": the report came back malformed, so there was no data to sync. Re-enable the sync to try again, and contact support if it keeps happening.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.