Conector do Octadesk: leve seus dados de suporte e CRM para o warehouse sem manter pipeline
Conector gerenciado para sincronizar chats, tickets, contatos, organizações e survey submissions do Octadesk para BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse e Amazon S3. Sem pipeline para manter.
Conector gerenciado para sincronizar chats, mensagens, tickets, contatos, organizações e survey submissions do Octadesk para BigQuery, Redshift, Snowflake, Databricks, ClickHouse, PostgreSQL, Supabase e Amazon S3. Crie sua conta e teste agora.
Todo time de dados que atende uma empresa com operação de CX eventualmente chega no mesmo impasse: os dados de atendimento vivem no Octadesk, o restante do stack analítico vive no warehouse, e juntar os dois vira um projeto de engenharia que ninguém planejou. O que começa como um script Python rodando no cron do EC2 se transforma, três meses depois, em um pipeline que ninguém entende, que falha silenciosamente, e que nenhum engineer quer herdar.
A Erathos lança hoje o conector gerenciado para o Octadesk. Quinze endpoints disponíveis, nove destinos suportados, zero código de pipeline para escrever ou manter.
O problema com pipelines de Octadesk feitos na mão
A API do Octadesk é autenticada via API Key, com a URL base da conta (https://suaempresa.octadesk.services) variando por tenant. O padrão é simples o suficiente para convencer qualquer engineer a construir uma integração própria numa tarde.
O custo real aparece depois, e ele é previsível.
Paginação não uniforme por endpoint. Chats e mensagens têm volume e comportamento de paginação diferentes de tickets e contatos. A lógica que funciona para um não necessariamente funciona para o outro, e quando o Octadesk ajusta algum default de page size ou muda o cursor, o pipeline para de trazer todos os registros sem lançar erro.
Rate limit silencioso. A API do Octadesk opera com rate limiting. Em uma extração incremental normal, para volumes de médio porte, você fica abaixo do limite. Quando você faz um backfill histórico ou quando o Salesforce do cliente está disparando eventos em cascata, o pipeline começa a receber 429s. Se o seu retry não está implementado corretamente com backoff exponencial, você perde janelas inteiras de dado e não sabe.
Schema evolution sem aviso. Campos novos aparecem, campos existentes ficam nullable, estruturas aninhadas mudam. O seu modelo dbt que rodava limpo começa a falhar em produção, ou pior: continua rodando, mas com coalesce em campo que sumiu. A inconsistência vai parar no dashboard do time de CS antes de chegar no seu monitor.
Observabilidade que não existe. Um 200 OK na chamada HTTP não significa que os dados chegaram corretos. Sem contagem de registros por endpoint por execução, sem comparação com a janela anterior, sem alerta de queda de volume, você está voando cego. O pipeline que rodou com sucesso pode ter trazido zero tickets novos porque o cursor ficou preso.
O pior cenário não é o pipeline que quebra e manda alerta. É o pipeline que executa com sucesso e entrega dado errado, e a métrica de SLA que sobe pro dashboard de CS já está calculada sobre uma base podre.
O que você pode fazer quando os dados do Octadesk chegam no warehouse
Antes de detalhar o conector, vale documentar o que se ganha de fato quando esses dados saem do SaaS e entram modelados ao lado do restante do seu stack.
Análise de SLA end-to-end com dado cruzado
Com tickets e ticket_interactions no warehouse, você consegue calcular o tempo de primeira resposta, o tempo de resolução por tipo e por canal com precisão por registro, não como agregado exportado do painel do Octadesk.
Esse modelo não existe nativamente em nenhum painel do Octadesk. Ele só é possível quando o dado está no seu warehouse, ao lado das outras tabelas do seu modelo.
Combinar atendimento com dados de produto e CRM
Cruzando contacts e organizations com a tabela de contas do seu CRM (Salesforce, HubSpot, ou o que estiver no warehouse), você responde perguntas como: clientes do plano enterprise têm SLA melhor do que os do plano starter? Quais organizações abrem mais tickets repetidos para o mesmo problema? Quais canais têm maior taxa de reabertura?
Essas perguntas parecem simples, mas exigem que organizations do Octadesk e accounts do CRM vivam no mesmo warehouse e sejam unidas por um campo de negócio (geralmente o domínio de email ou um ID externo).
Análise de sentimento e feedback com survey submissions
O endpoint survey_submissions traz as respostas de CSAT e NPS coletadas pelo Octadesk. Com isso no warehouse, você modela evolução de NPS por cohort de cliente, identifica quais tipos de ticket geram pior satisfação, e cruza CSAT com dados de produto para fechar o loop entre experiência do produto e qualidade do suporte.
Volume e performance por canal e grupo
Com ticket_channels, ticket_groups e ticket_status, você monta uma visão de throughput por fila de atendimento com granularidade por dia ou por hora. Diferente dos relatórios nativos do Octadesk, que são pré-agregados, aqui você tem o dado bruto para construir qualquer janela de tempo ou qualquer dimensão que o negócio precisar.
Análise de conversas de WhatsApp e chat com chats e messages
Os endpoints chats e messages trazem o histórico de conversas. Isso abre a possibilidade de análise de volume por horário, identificação de picos de demanda, categorização por palavras-chave, e até integração com modelos de LLM para classificação automática de intenção, tudo fora do Octadesk, no seu próprio ambiente.
O que está disponível no conector
O conector do Octadesk entrega quinze endpoints prontos para serem materializados no seu warehouse de destino:
Endpoint | O que contém |
|---|---|
| Conversas de chat e WhatsApp |
| Mensagens individuais por conversa |
| Eventos da plataforma |
| Contatos cadastrados |
| Tickets de suporte |
| Interações e respostas por ticket |
| Tags aplicadas a tickets |
| Grupos de atendimento |
| Formulários de abertura de ticket |
| Prioridades configuradas |
| Tipos de ticket |
| Canais de atendimento |
| Status de ticket |
| Organizações/contas |
| Respostas de CSAT e NPS |
Os destinos suportados são BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse e Amazon S3.
Como autenticar
A autenticação do conector requer três campos:
URL: a URL base da sua conta Octadesk (ex:
https://suaempresa.octadesk.services)Token: a API Key da sua conta
Agent Email: o email do agente Octadesk associado à chave
Para encontrar o token, navegue dentro do Octadesk em Configurações > WhatsApp API > Gerar API Key (Gerar apiKey). A URL base da conta está disponível no mesmo caminho, em Configurações > WhatsApp API > Base URL.
O processo completo está documentado em docs.erathos.com/connectors/apis/octadesk.
Por que terceirizar a ingestão para a Erathos
A premissa do conector é direta: a engenharia de manutenção da ingestão não deveria ser responsabilidade do seu time de dados. Paginação, rate limit, retry com backoff, schema evolution, alerta de falha, alerta de queda de volume, backfill. Tudo isso é responsabilidade de quem opera a plataforma de ingestão.
Com o conector configurado, a plataforma entrega:
Visibilidade ponta a ponta de cada execução. Tempo de extração por endpoint, contagem de registros por janela, quais janelas foram processadas, onde houve retentativa. Quando uma métrica de SLA muda no dashboard e o time de CS abre um chamado para o time de dados, você tem a trilha completa para encontrar a causa raiz.
Alertas configurados de fábrica. Falha de execução, queda de volume por endpoint e atraso de janela são detectados e roteados pelas integrações de alerta que o time já usa. Você não escreve esse código.
Reprocessamento como operação suportada. Quando você precisa reprocessar uma janela — porque mudou a lógica do modelo dbt ou porque recebeu uma correção da fonte — isso é uma operação de plataforma, não uma sequência de DELETE + INSERT improvisada no warehouse.
Paginação correta, gestão de rate limit, evolução de schema e backfill são responsabilidade da plataforma. O time de dados foca no modelo, não no encanamento.
Pipelines disponíveis
O conector do Octadesk está disponível com os seguintes destinos:
Comece agora
Crie sua conta na Erathos e conecte o Octadesk ao seu warehouse em minutos. Com a URL base, o token e o email do agente, os primeiros dados chegam ao destino sem nenhum código de pipeline para escrever, manter ou monitorar.
Dados de atendimento gerados todo dia não deveriam ficar trancados em um SaaS, desconectados do restante do seu modelo analítico. Ou pior: em um pipeline caseiro que vai custar atenção do time todo mês para sempre.
Veja a documentação completa do conector em docs.erathos.com/connectors/apis/octadesk.
Conector gerenciado para sincronizar chats, mensagens, tickets, contatos, organizações e survey submissions do Octadesk para BigQuery, Redshift, Snowflake, Databricks, ClickHouse, PostgreSQL, Supabase e Amazon S3. Crie sua conta e teste agora.
Todo time de dados que atende uma empresa com operação de CX eventualmente chega no mesmo impasse: os dados de atendimento vivem no Octadesk, o restante do stack analítico vive no warehouse, e juntar os dois vira um projeto de engenharia que ninguém planejou. O que começa como um script Python rodando no cron do EC2 se transforma, três meses depois, em um pipeline que ninguém entende, que falha silenciosamente, e que nenhum engineer quer herdar.
A Erathos lança hoje o conector gerenciado para o Octadesk. Quinze endpoints disponíveis, nove destinos suportados, zero código de pipeline para escrever ou manter.
O problema com pipelines de Octadesk feitos na mão
A API do Octadesk é autenticada via API Key, com a URL base da conta (https://suaempresa.octadesk.services) variando por tenant. O padrão é simples o suficiente para convencer qualquer engineer a construir uma integração própria numa tarde.
O custo real aparece depois, e ele é previsível.
Paginação não uniforme por endpoint. Chats e mensagens têm volume e comportamento de paginação diferentes de tickets e contatos. A lógica que funciona para um não necessariamente funciona para o outro, e quando o Octadesk ajusta algum default de page size ou muda o cursor, o pipeline para de trazer todos os registros sem lançar erro.
Rate limit silencioso. A API do Octadesk opera com rate limiting. Em uma extração incremental normal, para volumes de médio porte, você fica abaixo do limite. Quando você faz um backfill histórico ou quando o Salesforce do cliente está disparando eventos em cascata, o pipeline começa a receber 429s. Se o seu retry não está implementado corretamente com backoff exponencial, você perde janelas inteiras de dado e não sabe.
Schema evolution sem aviso. Campos novos aparecem, campos existentes ficam nullable, estruturas aninhadas mudam. O seu modelo dbt que rodava limpo começa a falhar em produção, ou pior: continua rodando, mas com coalesce em campo que sumiu. A inconsistência vai parar no dashboard do time de CS antes de chegar no seu monitor.
Observabilidade que não existe. Um 200 OK na chamada HTTP não significa que os dados chegaram corretos. Sem contagem de registros por endpoint por execução, sem comparação com a janela anterior, sem alerta de queda de volume, você está voando cego. O pipeline que rodou com sucesso pode ter trazido zero tickets novos porque o cursor ficou preso.
O pior cenário não é o pipeline que quebra e manda alerta. É o pipeline que executa com sucesso e entrega dado errado, e a métrica de SLA que sobe pro dashboard de CS já está calculada sobre uma base podre.
O que você pode fazer quando os dados do Octadesk chegam no warehouse
Antes de detalhar o conector, vale documentar o que se ganha de fato quando esses dados saem do SaaS e entram modelados ao lado do restante do seu stack.
Análise de SLA end-to-end com dado cruzado
Com tickets e ticket_interactions no warehouse, você consegue calcular o tempo de primeira resposta, o tempo de resolução por tipo e por canal com precisão por registro, não como agregado exportado do painel do Octadesk.
Esse modelo não existe nativamente em nenhum painel do Octadesk. Ele só é possível quando o dado está no seu warehouse, ao lado das outras tabelas do seu modelo.
Combinar atendimento com dados de produto e CRM
Cruzando contacts e organizations com a tabela de contas do seu CRM (Salesforce, HubSpot, ou o que estiver no warehouse), você responde perguntas como: clientes do plano enterprise têm SLA melhor do que os do plano starter? Quais organizações abrem mais tickets repetidos para o mesmo problema? Quais canais têm maior taxa de reabertura?
Essas perguntas parecem simples, mas exigem que organizations do Octadesk e accounts do CRM vivam no mesmo warehouse e sejam unidas por um campo de negócio (geralmente o domínio de email ou um ID externo).
Análise de sentimento e feedback com survey submissions
O endpoint survey_submissions traz as respostas de CSAT e NPS coletadas pelo Octadesk. Com isso no warehouse, você modela evolução de NPS por cohort de cliente, identifica quais tipos de ticket geram pior satisfação, e cruza CSAT com dados de produto para fechar o loop entre experiência do produto e qualidade do suporte.
Volume e performance por canal e grupo
Com ticket_channels, ticket_groups e ticket_status, você monta uma visão de throughput por fila de atendimento com granularidade por dia ou por hora. Diferente dos relatórios nativos do Octadesk, que são pré-agregados, aqui você tem o dado bruto para construir qualquer janela de tempo ou qualquer dimensão que o negócio precisar.
Análise de conversas de WhatsApp e chat com chats e messages
Os endpoints chats e messages trazem o histórico de conversas. Isso abre a possibilidade de análise de volume por horário, identificação de picos de demanda, categorização por palavras-chave, e até integração com modelos de LLM para classificação automática de intenção, tudo fora do Octadesk, no seu próprio ambiente.
O que está disponível no conector
O conector do Octadesk entrega quinze endpoints prontos para serem materializados no seu warehouse de destino:
Endpoint | O que contém |
|---|---|
| Conversas de chat e WhatsApp |
| Mensagens individuais por conversa |
| Eventos da plataforma |
| Contatos cadastrados |
| Tickets de suporte |
| Interações e respostas por ticket |
| Tags aplicadas a tickets |
| Grupos de atendimento |
| Formulários de abertura de ticket |
| Prioridades configuradas |
| Tipos de ticket |
| Canais de atendimento |
| Status de ticket |
| Organizações/contas |
| Respostas de CSAT e NPS |
Os destinos suportados são BigQuery, Redshift, Databricks, PostgreSQL, Supabase, Azure Synapse e Amazon S3.
Como autenticar
A autenticação do conector requer três campos:
URL: a URL base da sua conta Octadesk (ex:
https://suaempresa.octadesk.services)Token: a API Key da sua conta
Agent Email: o email do agente Octadesk associado à chave
Para encontrar o token, navegue dentro do Octadesk em Configurações > WhatsApp API > Gerar API Key (Gerar apiKey). A URL base da conta está disponível no mesmo caminho, em Configurações > WhatsApp API > Base URL.
O processo completo está documentado em docs.erathos.com/connectors/apis/octadesk.
Por que terceirizar a ingestão para a Erathos
A premissa do conector é direta: a engenharia de manutenção da ingestão não deveria ser responsabilidade do seu time de dados. Paginação, rate limit, retry com backoff, schema evolution, alerta de falha, alerta de queda de volume, backfill. Tudo isso é responsabilidade de quem opera a plataforma de ingestão.
Com o conector configurado, a plataforma entrega:
Visibilidade ponta a ponta de cada execução. Tempo de extração por endpoint, contagem de registros por janela, quais janelas foram processadas, onde houve retentativa. Quando uma métrica de SLA muda no dashboard e o time de CS abre um chamado para o time de dados, você tem a trilha completa para encontrar a causa raiz.
Alertas configurados de fábrica. Falha de execução, queda de volume por endpoint e atraso de janela são detectados e roteados pelas integrações de alerta que o time já usa. Você não escreve esse código.
Reprocessamento como operação suportada. Quando você precisa reprocessar uma janela — porque mudou a lógica do modelo dbt ou porque recebeu uma correção da fonte — isso é uma operação de plataforma, não uma sequência de DELETE + INSERT improvisada no warehouse.
Paginação correta, gestão de rate limit, evolução de schema e backfill são responsabilidade da plataforma. O time de dados foca no modelo, não no encanamento.
Pipelines disponíveis
O conector do Octadesk está disponível com os seguintes destinos:
Comece agora
Crie sua conta na Erathos e conecte o Octadesk ao seu warehouse em minutos. Com a URL base, o token e o email do agente, os primeiros dados chegam ao destino sem nenhum código de pipeline para escrever, manter ou monitorar.
Dados de atendimento gerados todo dia não deveriam ficar trancados em um SaaS, desconectados do restante do seu modelo analítico. Ou pior: em um pipeline caseiro que vai custar atenção do time todo mês para sempre.
Veja a documentação completa do conector em docs.erathos.com/connectors/apis/octadesk.