Octadesk connector: load your support and CRM data into your warehouse without maintaining pipelines
Managed connector to sync chats, tickets, contacts, organizations, and survey submissions from Octadesk to BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse, and Amazon S3. Zero pipeline maintenance.
Octadesk connector: bring your support and CRM data to the warehouse without maintaining a pipeline
Managed connector to sync chats, messages, tickets, contacts, organizations, and survey submissions from Octadesk to BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse, and Amazon S3. Create your account and test it now.
Every data team supporting a company with a CX operation eventually runs into the same bottleneck: customer support data lives in Octadesk, the rest of the analytical stack lives in the warehouse, and joining the two becomes an unplanned engineering project. What starts as a Python script running via cron on EC2 turns, three months later, into a pipeline that nobody understands, that fails silently, and that no engineer wants to inherit.
Erathos is launching today the managed connector for Octadesk. Fifteen available endpoints, nine supported destinations, zero pipeline code to write or maintain.
The problem with custom-built Octadesk pipelines
The Octadesk API is authenticated via API Key, with the account's base URL (https://yourcompany.octadesk.services) varying by tenant. The pattern is simple enough to convince any engineer to build a custom integration in an afternoon.
The real cost comes later, and it's predictable.
Non-uniform pagination per endpoint. Chats and messages have different volume and pagination behaviors compared to tickets and contacts. Logic that works for one doesn't necessarily work for another, and when Octadesk adjusts a default page size or changes the cursor, the pipeline stops bringing in all records without raising an error.
Silent rate limiting. The Octadesk API operates with rate limiting. In a normal incremental sync for medium volumes, you stay below the limit. When you run a historical backfill or when the customer's Salesforce is triggering cascading events, the pipeline starts getting 429s. If your retry isn't properly implemented with exponential backoff, you lose entire data windows and won't even know it.
Unannounced schema evolution. New fields appear, existing fields become nullable, nested structures change. Your dbt model that used to run smoothly starts failing in production, or worse: it keeps running, but with a coalesce on a field that disappeared. This inconsistency hits the CS team's dashboard before it ever hits your monitoring.
Non-existent observability. A 200 OK on an HTTP call doesn't mean the data arrived correctly. Without record counts per endpoint per run, comparison with the previous window, or volume drop alerts, you are flying blind. A pipeline that ran successfully could have loaded zero new tickets because the cursor got stuck.
The worst-case scenario isn't the pipeline that breaks and sends an alert. It's the pipeline that runs successfully and delivers bad data, and the SLA metric going up to the CS dashboard is already calculated over a broken source.
What you can do once Octadesk data hits the warehouse
Before detailing the connector, it's worth documenting what you actually gain when this data leaves the SaaS and lands modeled alongside the rest of your modern data stack.
End-to-end SLA analysis with joined data
With tickets and ticket_interactions in the warehouse, you can calculate first response time and resolution time by type and channel with record-level precision, rather than relying on aggregates exported from the Octadesk dashboard.
This model doesn't exist natively in any Octadesk dashboard. It's only possible when the data is in your warehouse, next to the other tables in your model.
Combine customer support with product and CRM data
By joining contacts and organizations with the accounts table from your CRM (Salesforce, HubSpot, or whatever is in your warehouse), you can answer questions like: do enterprise plan customers have better SLA than starter plan customers? Which organizations open more repetitive tickets for the same issue? Which channels have the highest reopen rate?
These questions sound simple, but they require Octadesk organizations and CRM accounts to live in the same warehouse and be joined by a business field (usually the email domain or an external ID).
Sentiment and feedback analysis with survey submissions
The survey_submissions endpoint brings CSAT and NPS responses collected by Octadesk. With this in the warehouse, you can model NPS evolution by customer cohort, identify which ticket types drive the worst satisfaction, and join CSAT with product data to close the loop between product experience and support quality.
Volume and performance by channel and group
With ticket_channels, ticket_groups, and ticket_status, you can build a throughput view by support queue with daily or hourly granularity. Unlike native Octadesk reports, which are pre-aggregated, here you have the raw data to build any time window or dimension the business needs.
WhatsApp and chat conversation analysis with chats and messages
The chats and messages endpoints bring conversation history. This opens up possibilities for volume analysis by time of day, identifying peak demand, keyword categorization, and even integrating with LLMs for automated intent classification — all outside of Octadesk, in your own environment.
What's available in the connector
The Octadesk connector delivers fifteen endpoints ready to be materialized in your destination warehouse:
Endpoint | What it contains |
|---|---|
| Chat and WhatsApp conversations |
| Individual messages per conversation |
| Platform events |
| Registered contacts |
| Support tickets |
| Interactions and responses per ticket |
| Tags applied to tickets |
| Support groups |
| Ticket creation forms |
| Configured priorities |
| Ticket types |
| Support channels |
| Ticket statuses |
| Organizations/accounts |
| CSAT and NPS answers |
Supported destinations are BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse, and Amazon S3.
How to authenticate
Connector authentication requires three fields:
URL: your Octadesk account base URL (e.g.,
https://yourcompany.octadesk.services)Token: your account API Key
Agent Email: the Octadesk agent email associated with the key
To find the token within Octadesk, navigate to Settings > WhatsApp API > Generate API Key (Gerar apiKey). The account base URL is available under the same path, under Settings > WhatsApp API > Base URL.
The complete process is documented at docs.erathos.com/connectors/apis/octadesk.
Why outsource ingestion to Erathos
The connector's premise is straightforward: maintaining ingestion pipelines shouldn't be your data team's responsibility. Pagination, rate limits, retry with backoff, schema evolution, failure alerts, volume drop alerts, backfills. All of this is the responsibility of whoever runs the ingestion platform.
With the connector configured, the platform delivers:
End-to-end visibility of every execution. Extraction time per endpoint, record counts per window, which windows were processed, where retries occurred. When an SLA metric changes on the dashboard and the CS team opens a ticket for the data team, you have the full lineage to find the root cause.
Out-of-the-box alerting. Execution failures, volume drops per endpoint, and window delays are detected and routed through the alerting integrations your team already uses. You don't write this code.
Reprocessing as a supported platform operation. When you need to reprocess a window — whether because you changed dbt model logic or received a source correction — this is a platform operation, not a sequence of improvised DELETE + INSERT statements in the warehouse.
Proper pagination, rate limit management, schema evolution, and backfills are the platform's responsibility. The data team focuses on the model, not the plumbing.
Available pipelines
The Octadesk connector is available with the following destinations:
Get started now
Create your Erathos account and connect Octadesk to your warehouse in minutes. With the base URL, token, and agent email, your first data arrives at the destination with zero pipeline code to write, maintain, or monitor.
Customer support data generated every day shouldn't be locked inside a SaaS, disconnected from the rest of your analytical model. Even worse: in a home-grown pipeline that will cost your team attention every single month, forever.
See the full connector documentation at docs.erathos.com/connectors/apis/octadesk.
Octadesk connector: bring your support and CRM data to the warehouse without maintaining a pipeline
Managed connector to sync chats, messages, tickets, contacts, organizations, and survey submissions from Octadesk to BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse, and Amazon S3. Create your account and test it now.
Every data team supporting a company with a CX operation eventually runs into the same bottleneck: customer support data lives in Octadesk, the rest of the analytical stack lives in the warehouse, and joining the two becomes an unplanned engineering project. What starts as a Python script running via cron on EC2 turns, three months later, into a pipeline that nobody understands, that fails silently, and that no engineer wants to inherit.
Erathos is launching today the managed connector for Octadesk. Fifteen available endpoints, nine supported destinations, zero pipeline code to write or maintain.
The problem with custom-built Octadesk pipelines
The Octadesk API is authenticated via API Key, with the account's base URL (https://yourcompany.octadesk.services) varying by tenant. The pattern is simple enough to convince any engineer to build a custom integration in an afternoon.
The real cost comes later, and it's predictable.
Non-uniform pagination per endpoint. Chats and messages have different volume and pagination behaviors compared to tickets and contacts. Logic that works for one doesn't necessarily work for another, and when Octadesk adjusts a default page size or changes the cursor, the pipeline stops bringing in all records without raising an error.
Silent rate limiting. The Octadesk API operates with rate limiting. In a normal incremental sync for medium volumes, you stay below the limit. When you run a historical backfill or when the customer's Salesforce is triggering cascading events, the pipeline starts getting 429s. If your retry isn't properly implemented with exponential backoff, you lose entire data windows and won't even know it.
Unannounced schema evolution. New fields appear, existing fields become nullable, nested structures change. Your dbt model that used to run smoothly starts failing in production, or worse: it keeps running, but with a coalesce on a field that disappeared. This inconsistency hits the CS team's dashboard before it ever hits your monitoring.
Non-existent observability. A 200 OK on an HTTP call doesn't mean the data arrived correctly. Without record counts per endpoint per run, comparison with the previous window, or volume drop alerts, you are flying blind. A pipeline that ran successfully could have loaded zero new tickets because the cursor got stuck.
The worst-case scenario isn't the pipeline that breaks and sends an alert. It's the pipeline that runs successfully and delivers bad data, and the SLA metric going up to the CS dashboard is already calculated over a broken source.
What you can do once Octadesk data hits the warehouse
Before detailing the connector, it's worth documenting what you actually gain when this data leaves the SaaS and lands modeled alongside the rest of your modern data stack.
End-to-end SLA analysis with joined data
With tickets and ticket_interactions in the warehouse, you can calculate first response time and resolution time by type and channel with record-level precision, rather than relying on aggregates exported from the Octadesk dashboard.
This model doesn't exist natively in any Octadesk dashboard. It's only possible when the data is in your warehouse, next to the other tables in your model.
Combine customer support with product and CRM data
By joining contacts and organizations with the accounts table from your CRM (Salesforce, HubSpot, or whatever is in your warehouse), you can answer questions like: do enterprise plan customers have better SLA than starter plan customers? Which organizations open more repetitive tickets for the same issue? Which channels have the highest reopen rate?
These questions sound simple, but they require Octadesk organizations and CRM accounts to live in the same warehouse and be joined by a business field (usually the email domain or an external ID).
Sentiment and feedback analysis with survey submissions
The survey_submissions endpoint brings CSAT and NPS responses collected by Octadesk. With this in the warehouse, you can model NPS evolution by customer cohort, identify which ticket types drive the worst satisfaction, and join CSAT with product data to close the loop between product experience and support quality.
Volume and performance by channel and group
With ticket_channels, ticket_groups, and ticket_status, you can build a throughput view by support queue with daily or hourly granularity. Unlike native Octadesk reports, which are pre-aggregated, here you have the raw data to build any time window or dimension the business needs.
WhatsApp and chat conversation analysis with chats and messages
The chats and messages endpoints bring conversation history. This opens up possibilities for volume analysis by time of day, identifying peak demand, keyword categorization, and even integrating with LLMs for automated intent classification — all outside of Octadesk, in your own environment.
What's available in the connector
The Octadesk connector delivers fifteen endpoints ready to be materialized in your destination warehouse:
Endpoint | What it contains |
|---|---|
| Chat and WhatsApp conversations |
| Individual messages per conversation |
| Platform events |
| Registered contacts |
| Support tickets |
| Interactions and responses per ticket |
| Tags applied to tickets |
| Support groups |
| Ticket creation forms |
| Configured priorities |
| Ticket types |
| Support channels |
| Ticket statuses |
| Organizations/accounts |
| CSAT and NPS answers |
Supported destinations are BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse, and Amazon S3.
How to authenticate
Connector authentication requires three fields:
URL: your Octadesk account base URL (e.g.,
https://yourcompany.octadesk.services)Token: your account API Key
Agent Email: the Octadesk agent email associated with the key
To find the token within Octadesk, navigate to Settings > WhatsApp API > Generate API Key (Gerar apiKey). The account base URL is available under the same path, under Settings > WhatsApp API > Base URL.
The complete process is documented at docs.erathos.com/connectors/apis/octadesk.
Why outsource ingestion to Erathos
The connector's premise is straightforward: maintaining ingestion pipelines shouldn't be your data team's responsibility. Pagination, rate limits, retry with backoff, schema evolution, failure alerts, volume drop alerts, backfills. All of this is the responsibility of whoever runs the ingestion platform.
With the connector configured, the platform delivers:
End-to-end visibility of every execution. Extraction time per endpoint, record counts per window, which windows were processed, where retries occurred. When an SLA metric changes on the dashboard and the CS team opens a ticket for the data team, you have the full lineage to find the root cause.
Out-of-the-box alerting. Execution failures, volume drops per endpoint, and window delays are detected and routed through the alerting integrations your team already uses. You don't write this code.
Reprocessing as a supported platform operation. When you need to reprocess a window — whether because you changed dbt model logic or received a source correction — this is a platform operation, not a sequence of improvised DELETE + INSERT statements in the warehouse.
Proper pagination, rate limit management, schema evolution, and backfills are the platform's responsibility. The data team focuses on the model, not the plumbing.
Available pipelines
The Octadesk connector is available with the following destinations:
Get started now
Create your Erathos account and connect Octadesk to your warehouse in minutes. With the base URL, token, and agent email, your first data arrives at the destination with zero pipeline code to write, maintain, or monitor.
Customer support data generated every day shouldn't be locked inside a SaaS, disconnected from the rest of your analytical model. Even worse: in a home-grown pipeline that will cost your team attention every single month, forever.
See the full connector documentation at docs.erathos.com/connectors/apis/octadesk.