# Conector Slack: sincronize mensagens, canais e arquivos do workspace no seu data warehouse > Conector da Erathos sincroniza mensagens, canais, arquivos e logs do Slack para o seu data warehouse. BigQuery, Redshift e mais, sem pipeline manual. Source: https://www.erathos.com/blog/conector-slack-lancamento Published: 2026-09-13 Category: Novos Conectores ![New Connector Slack](https://cms-media.erathos.com/New Connector Slack.png) A Erathos lança o conector gerenciado para o [Slack](https://www.erathos.com/connectors/slack). Quarenta endpoints disponíveis, dez destinos suportados, zero código de pipeline para escrever ou manter. O Slack expõe uma Web API autenticada por Bot User OAuth Token, o que permite, em teoria, construir uma extração própria. Na prática, isso significa escrever e manter um pipeline de ETL customizado para lidar com paginação por cursor, rate limit por tier de método e payloads que variam por tipo de mensagem, algo que a maioria dos times de dados descobre tarde demais que não escala. O conector da Erathos resolve essa integração como serviço gerenciado, sem exigir que o time escreva ou mantenha esse código. Todo time de dados que dá suporte a uma operação que trabalha dentro do Slack chega no mesmo impasse: as conversas, decisões e arquivos que movem o dia a dia ficam presos no workspace, 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 de uma VM se transforma, três meses depois, em um pipeline que ninguém entende, que falha silenciosamente e que nenhum engenheiro quer herdar. ## O problema com pipelines de Slack feitos na mão A Web API do Slack é autenticada por um Bot User OAuth Token com escopos granulares, e os métodos de leitura retornam dados paginados por cursor. O padrão é simples o suficiente para convencer qualquer engenheiro a construir uma integração própria numa tarde. O custo real aparece depois, e ele é previsível. Paginação que varia de método para método. conversations.history, conversations.replies, files.list e cada método de busca iteram com cursor e limit próprios, com defaults diferentes entre endpoints. Um erro na lógica de iteração não lança exceção: o pipeline simplesmente para de trazer páginas antigas e segue executando com sucesso. Rate limit por tier de método. A Web API do Slack aplica limites de requisição por método, organizados em tiers. Em uma extração incremental normal você fica abaixo do limite. Num backfill histórico, o pipeline começa a receber 429 com um header de Retry-After. Se o retry não respeita esse header com backoff, você perde janelas inteiras de dado sem saber. Escopo faltando não gera erro, gera dado ausente. O token do bot precisa dos scopes corretos para cada endpoint: sem channels:history o histórico de canais públicos não vem, sem groups:history o de canais privados também não. O auth.test continua passando, o pipeline continua verde, e o warehouse fica com uma base incompleta que ninguém detecta. Histórico vivo. Mensagens são editadas e apagadas depois de postadas, e as respostas de thread chegam por um endpoint separado. Como o ts de uma mensagem não muda quando ela é editada, uma sincronização incremental por ts não revisita edições: capturar isso exige uma estratégia de reprocessamento que a maioria dos pipelines caseiros não tem. Evolução de schema sem aviso. Payloads de mensagem variam por subtype, blocks e attachments mudam de forma conforme o app que os gerou, e campos de perfil customizados do workspace entram como colunas na tabela de usuários. O modelo dbt que rodava limpo começa a falhar em produção, ou pior: continua rodando com coalesce em campo que sumiu. A inconsistência vai parar no dashboard antes de chegar no seu monitor. Observabilidade que não existe. Um 200 OK na chamada HTTP não significa que os dados chegaram completos. 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 metade das mensagens porque um canal privado ficou fora do escopo do token. 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 tempo de resposta que sobe pro dashboard do time já está calculada sobre uma base incompleta. ## O que é possível fazer quando os dados do Slack chegam no warehouse Antes de detalhar o conector, vale documentar o que se ganha de fato quando as conversas, os arquivos e os usuários do workspace saem do SaaS e entram modelados ao lado do restante do seu stack. ### Engajamento interno por canal, time e horário Com messages, users e users\_conversations no warehouse, você mede volume de mensagens por canal por dia, concentração de participação por pessoa, horários de pico e adoção por área da empresa ao cruzar o email do perfil com a base de colaboradores do RH. Os relatórios nativos do Slack entregam agregados pré-calculados; qualquer dimensão que o negócio escolher exige o dado bruto no warehouse. ### Tempo de primeira resposta no suporte interno Com messages e thread\_replies unidos por thread\_ts, você calcula o tempo de primeira resposta por thread nos canais de suporte, a distribuição por resolvedor e o SLA de atendimento interno de TI. Esse cálculo exige granularidade por registro e join entre mensagens e respostas de thread no mesmo banco, algo que nenhum painel nativo do Slack oferece. ### Conversas com clientes cruzadas com o CRM O Slack Connect traz parceiros e clientes para dentro do workspace. Com conversations marcadas como externas, conversation\_connect\_invites e team\_external\_teams, você identifica com quais workspaces externos a empresa conversa. Cruzando o email do profile de users com a base de contas do seu CRM, você responde: quais contas concentram mais interação, quais canais compartilhados ficaram inativos, se a frequência de conversa subiu antes de uma renovação. Só é possível com Slack e CRM no mesmo warehouse, unidos por um campo de negócio. ### Trilha de auditoria de acessos e integrações team\_access\_logs registra IP, user agent, país e horários de acesso por usuário, e team\_integration\_logs registra cada mudança em integrações e apps. Sincronizando todos os dias, o warehouse acumula uma trilha histórica contínua que consultas pontuais na API não entregam, base para revisões de segurança, conformidade e investigação de incidentes, inclusive cruzando logs de integração com mudanças de schema no seu próprio pipeline. ### Mapa do conhecimento que circula no workspace files, file\_comments, bookmarks e pins mostram o que é compartilhado, comentado e fixado. search\_messages, search\_files e search\_all permitem montar um índice pesquisável do que já foi dito e anexado. No warehouse, esse acervo cruza com dados de projeto e produto para revelar quais materiais sustentam as decisões do time e quais canais concentram conhecimento crítico. ## O que está disponível no conector O conector do Slack entrega quarenta endpoints prontos para serem materializados no seu warehouse de destino: Endpoint O que contém conversations Canais públicos e privados, grupos, DMs e conversas em grupo, com tópico, propósito e contagem de membros conversation\_members Membros participantes de cada conversa messages Mensagens postadas em cada conversa, com autor, texto, reações, anexos e permalink thread\_replies Respostas dentro de threads, com o mesmo esquema das mensagens bookmarks Itens salvos como bookmark nos canais, com título, link e autor pins Mensagens e arquivos fixados nos canais conversation\_connect\_invites Convites do Slack Connect enviados a workspaces externos, com validade e canal de destino conversation\_connect\_invite\_requests Solicitações de conexão recebidas via Slack Connect e status de aprovação users Usuários do workspace com perfil, fuso horário e flags de admin e bot; campos de perfil customizados entram como colunas extras users\_get\_presence Presença de cada usuário: online, away, última atividade e contagem de conexões users\_conversations Conversas em que cada usuário participa users\_profile\_fields Definição dos campos de perfil customizados do workspace, com rótulo, tipo e valores possíveis files Arquivos enviados no workspace, com tipo, tamanho, autor, canais compartilhados e URLs file\_comments Comentários em arquivos, com autor e reações files\_remote Arquivos remotos compartilhados de serviços externos, com app de origem usergroups Grupos de usuários do workspace, com handle, descrição e contagem de membros usergroup\_members Membros de cada grupo de usuários team\_info Informações do workspace: nome, domínio, URL e verificação enterprise auth\_teams Workspaces aos quais o app instalado tem acesso team\_preferences Preferências de configuração do workspace, como permissões de canal e integrações team\_billable\_info Marcador de usuários faturáveis (billable) por user\_id team\_access\_logs Logs de acesso dos usuários: IP, user agent, país, região e horários team\_integration\_logs Mudanças em integrações e apps: serviço, tipo de mudança, escopo e canal team\_external\_teams Workspaces externos conectados ao seu via Slack Connect apps\_activities Atividades de apps no workspace, com usuário, entidade e tipo de evento apps\_event\_authorizations Autorizações de eventos de apps por workspace, enterprise e usuário apps\_datastore\_query Registros consultados no datastore de apps da plataforma Slack emoji Emoji customizados do workspace, com nome e URL reactions Reações de emoji aplicadas a mensagens, arquivos e comentários stars Itens marcados com estrela: mensagens, arquivos, comentários e canais reminders Lembretes criados pelos usuários, com recorrência e horário scheduled\_messages Mensagens agendadas para envio futuro, com canal, texto e horário search\_messages Resultados da busca de mensagens no workspace, com score e canal search\_files Resultados da busca de arquivos no workspace, com score e metadados search\_all Resultados combinados de busca de mensagens e arquivos assistant\_search\_context Contexto de busca do assistente: mensagens, arquivos, canais e usuários por consulta list\_items Itens de Lists, o gerenciador de tarefas do Slack, com campos customizados workflows\_featured Workflows destacados no workspace e os canais em que aparecem functions\_workflows\_steps Steps executados por workflows e funções da plataforma, com inputs e outputs dnd\_team\_info Status de não perturbe (DND) por usuário, com janela de ativação Seis endpoints têm sincronização incremental: messages e thread\_replies com cursor em ts, files e files\_remote com cursor em created, scheduled\_messages com cursor em post\_at e apps\_activities com cursor em created. Os demais operam em full refresh, o que faz sentido para tabelas de configuração que mudam pouco. O relacionamento entre as entidades vem preservado no destino: conversas pai de membros, mensagens e threads, bookmarks e pins; usuários pai de presença, logs e grupos; arquivos pai de comentários. ## Como autenticar A autenticação do conector exige um único campo: - Token: o Bot User OAuth Token do Slack, que começa com xoxb-, usado para autenticar todas as chamadas à Web API - Onde encontrar: em api.slack.com/apps, crie um app ou selecione um existente, adicione em OAuth & Permissions os bot token scopes exigidos pelos endpoints que você quer sincronizar (channels:read, channels:history, groups:read, groups:history, im:read, im:history, mpim:read, mpim:history, users:read, files:read, emoji:read, pins:read, reactions:read, bookmarks:read, reminders:read, dnd:read, search:read, team:read, usergroups:read, entre outros), clique em Install to Workspace (ou Reinstall to Workspace) e copie o token exibido em Tokens for your workspace A Erathos valida as credenciais contra o endpoint auth.test do Slack antes de salvar a conexão. O processo completo, com a lista de escopos por endpoint, está documentado em docs.erathos.com/connectors/apis/slack. ## 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 por cursor, rate limit por tier, validação de escopo, retry com backoff, evolução de schema, 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 muda no dashboard e algum time 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, como Slack e e-mail. Você não escreve esse código. ### Reprocessamento como operação suportada Quando você precisa reprocessar uma janela, por exemplo para capturar mensagens editadas depois de mudar a lógica do modelo ou para corrigir um período afetado por mudança de escopo do token, 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 Slack está disponível com os seguintes destinos: - Slack → Azure SQL Server: [https://www.erathos.com/pipelines/slack-azure-sql-server](https://www.erathos.com/pipelines/slack-azure-sql-server) - Slack → Azure Synapse: [https://www.erathos.com/pipelines/slack-azure-synapse](https://www.erathos.com/pipelines/slack-azure-synapse) - Slack → BigQuery: [https://www.erathos.com/pipelines/slack-bigquery](https://www.erathos.com/pipelines/slack-bigquery) - Slack → ClickHouse: [https://www.erathos.com/pipelines/slack-clickhouse](https://www.erathos.com/pipelines/slack-clickhouse) - Slack → Databricks: [https://www.erathos.com/pipelines/slack-databricks](https://www.erathos.com/pipelines/slack-databricks) - Slack → PostgreSQL: [https://www.erathos.com/pipelines/slack-postgresql](https://www.erathos.com/pipelines/slack-postgresql) - Slack → Redshift: [https://www.erathos.com/pipelines/slack-redshift](https://www.erathos.com/pipelines/slack-redshift) - Slack → S3 Iceberg: [https://www.erathos.com/pipelines/slack-amazon-s3](https://www.erathos.com/pipelines/slack-amazon-s3) - Slack → Snowflake: [https://www.erathos.com/pipelines/slack-snowflake](https://www.erathos.com/pipelines/slack-snowflake) - Slack → Supabase: [https://www.erathos.com/pipelines/slack-supabase](https://www.erathos.com/pipelines/slack-supabase) ## Comece agora Crie sua conta na Erathos em [https://app.erathos.com/signup?slug=blog&button=cta&utm\_campaign=slack\_release](https://app.erathos.com/signup?slug=blog&button=cta&utm_campaign=slack_release) e conecte o Slack ao seu warehouse em minutos. Com o Bot User OAuth Token do seu app do Slack, os primeiros dados chegam ao destino sem nenhum código de pipeline para escrever, manter ou monitorar. Dados de conversas e colaboração 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 [https://docs.erathos.com/connectors/apis/slack](https://docs.erathos.com/connectors/apis/slack).