Skip to main content
O conector Apollo.io lê, pela API REST do Apollo, o CRM que o seu time mantém lá: contatos, contas, deals, usuários, tarefas abertas, chamadas e listas, com os estágios de cada entidade. Ele não consulta a base de prospecção do Apollo e não gasta créditos.

​
Capacidades

  • Traz ao Data Catalog os contatos, contas, deals, usuários, tarefas abertas, chamadas e listas do workspace, com os campos customizados de cada registro.
  • Chama só os endpoints de leitura de registros, que o Apollo cobra com 0 crédito. Os endpoints de enriquecimento e de busca na base do Apollo nunca são chamados.
  • Instala 9 tabelas clean prontas, com e-mail e domínio normalizados, o nome do estágio ao lado de cada entidade e as listas de cada contato e conta em tabelas próprias.
  • Alimenta o Memory com os nós Customer (contatos), Company (contas), Deal, Agent (usuários), Task, Call e List, ligados por dono, conta, contato e lista, e com a mudança de estágio do deal, o vencimento da tarefa e a chamada como eventos de linha do tempo. Contatos se unificam por e-mail com HubSpot, Salesforce, Pipedrive, Attio, Mailchimp e Fireflies, e contas se unificam por domínio com HubSpot, Salesforce, Pipedrive e Attio. Os nós só entram no grafo depois que a ontologia unificada é aplicada.

​
Recursos disponíveis

Todo recurso nasce desligado no Data Catalog. Você escolhe quais carregar depois de conectar. Os três recursos de estágio seguem o recurso dono no Data Catalog: contact_stages é carregado quando contacts está ligado, account_stages com accounts e opportunity_stages com opportunities. Você não os liga à parte.
As 9 tabelas clean do Apollo.io são instaladas quando você cria o conector, fora do contexto. Ligue no Data Catalog as que você quer usar. Cada uma passa a ser atualizada depois de cada sincronização. São elas: apollo_contacts, apollo_contact_labels, apollo_accounts, apollo_account_labels, apollo_opportunities, apollo_users, apollo_tasks, apollo_phone_calls e apollo_lists.

​
Como ler os dados

  • O conector grava só os campos listados de cada registro. Ficam de fora os hashes de e-mail que o Apollo anexa ao contato, as preferências pessoais de cada usuário e o link da gravação das chamadas.
  • Na clean, email e domain saem em minúsculas, e domain sem www.. O e-mail de placeholder que o Apollo mostra para um contato sem e-mail revelado (email_not_unlocked@…) vira NULL, para não juntar contatos diferentes num só.
  • phone de apollo_contacts só é preenchido quando o número é de uma linha pessoal (tipo mobile ou work_direct). O telefone da sede da empresa fica NULL, porque juntaria todos os contatos da empresa numa só pessoa no Memory. Todos os números do contato continuam em phone_numbers, na raw.
  • stage_name traz o nome do estágio ao lado do contato, da conta e do deal.
  • amount é o valor do deal na moeda do próprio deal, informada em currency_code. amount_in_team_currency é o mesmo valor convertido pelo Apollo para a moeda do time. Para somar deals de moedas diferentes, use amount_in_team_currency. O conector não converte moedas.
  • typed_custom_fields fica como JSON, com os campos customizados pelo id que o Apollo dá a cada campo.
  • apollo_contact_labels e apollo_account_labels têm uma linha por registro e lista.
  • source_updated_at é a última alteração do contato ou da lista no Apollo. Contas, deals e tarefas não têm esse dado na API.
  • Horários saem em UTC.

​
Permissões (ACL)

Esta fonte não define permissões por registro, então todo mundo que puder usar o conector vê todos os registros. Quem pode usar o conector é definido em Quem pode usar este conector: “Todos os usuários” ou “Apenas times específicos”. O Comportamento dos dados deste conector é sempre “Aberto”.

​
Como a fonte define acesso

No Apollo, cada contato, conta e deal tem um dono (owner_id), e o que cada membro vê no aplicativo depende do dono e do perfil de permissão dele. A API não expõe a regra de visibilidade nem o conteúdo dos perfis de permissão.

​
Como a Strattum traduz o acesso

A Strattum não grava permissão por item. A API key identifica o workspace, e o Apollo atribui as chamadas ao administrador mais antigo do time, então o conector lê o que esse administrador vê. Todas essas linhas ficam visíveis para quem pode usar o conector. O conector não oferece Exigir login na fonte como prova de identidade.

​
Quando a identidade não é encontrada

Não se aplica: nenhuma linha depende da identidade de quem consulta.

​
Quando a permissão é atualizada

Não há permissão da fonte para atualizar. O acesso depende só de Quem pode usar este conector.

​
Pré-requisitos

  • Um plano do Apollo com acesso à API.
  • Um administrador do Apollo, ou um membro com perfil de permissão que deixe criar API keys.
  • Uma API key master, ou uma API key com os endpoints da tabela abaixo marcados. A busca de chamadas só funciona com master key.
  • Uma só conexão Apollo.io por instalação. Com duas, o Data Catalog recusa a marcação de recursos e colunas, porque ela é guardada por tipo de conector.

​
Autenticação e escopos

A autenticação é por API key, enviada no header x-api-key em toda chamada. O Apollo tem dois tipos de chave: a master key, que acessa todos os endpoints, e a chave com endpoints selecionados, que só acessa os endpoints marcados. Com a chave do segundo tipo, marque o acesso de cada recurso que você vai carregar:
1

Abra as API keys no Apollo

No Apollo, vá em Settings → Integrations → API Keys e crie uma nova chave.
2

Escolha o tipo da chave

Ative Set as master key para dar acesso a todos os endpoints, ou marque os endpoints da tabela acima.
3

Copie a chave

Copie o valor da chave. Ele vai no campo API Key do Console.

​
Configuração no Console

1

Abra o assistente

Em Conectores, clique em + Nova Conexão e selecione Apollo.io, em CRM.
2

Preencha a conexão

Nome do Conector (Opcional): como a conexão aparece na lista. O padrão é Apollo.io.API Key (Obrigatório): a chave criada no Apollo.
3

Teste a conexão

Clique em Testar Conexão. Você só avança depois de um teste com sucesso ou com aviso. O teste consulta, ao mesmo tempo, os dez endpoints que o conector lê, pedindo um registro de cada. Passa quando todos respondem. Conecta com aviso quando parte dos endpoints recusa a chave, e o aviso diz, por recurso, o que marcar na chave. Você pode seguir sem esses recursos. Falha quando a chave é recusada, quando nenhum endpoint aceita a chave e quando o Apollo responde com limite de requisições.
4

Escolha a frequência

Em Sincronização (Obrigatório), escolha a frequência. O padrão do Apollo.io é uma vez por dia, às 06:00 UTC.
5

Defina o acesso

Em Permissionamento, defina Quem pode usar este conector. O Comportamento dos dados é sempre “Aberto”.
6

Revise e salve

Em Revisão, confira os dados e salve. A API key aparece mascarada.
7

Ligue os recursos no Data Catalog

No Data Catalog, ligue os recursos e as tabelas clean que você quer carregar.

​
Como a sincronização funciona

A frequência vem do passo Sincronização. O padrão é uma execução por dia, às 06:00 UTC: cada execução relê o CRM inteiro, e as cotas do Apollo são por dia. Full refresh. Todo recurso é reescrito por inteiro a cada execução. O Apollo não oferece filtro por data de alteração nas buscas nem uma lista de registros apagados, então só a releitura completa reflete o que mudou e o que foi removido. Um registro apagado no Apollo some da tabela na execução seguinte. Ordem. O conector lê os recursos selecionados um por um, com uma chamada por vez: contacts, accounts, opportunities, users, tasks, phone_calls, labels e os três estágios. Recurso desligado no Data Catalog não é lido. Paginação. As buscas de contatos, contas, deals, usuários, tarefas e chamadas são lidas de 100 em 100 registros. Depois de uma página cheia, o conector sempre pede a próxima, e a leitura termina na primeira página com menos de 100 registros. Listas e estágios vêm numa resposta só. Teto de 50.000. A busca do Apollo alcança no máximo 50.000 registros (500 páginas de 100). Quando um recurso tem 50.000 registros ou mais, o conector falha esse recurso antes de gravar qualquer linha, e a tabela anterior fica como estava. Os outros recursos seguem. Falhas. Um erro do Apollo num recurso, como falta de permissão da chave, não interrompe os outros recursos. A tabela do recurso que falhou não é tocada, e o log do conector registra o erro desse recurso, com o código HTTP e como corrigir. Se pelo menos um recurso carregou, a execução termina normalmente e as tabelas clean são atualizadas. Se nenhum recurso carregou, a execução termina com falha. Uma falha da própria plataforma, como o lake fora do ar, para a execução na hora. A leitura de cada recurso tenta de novo até 3 vezes, depois de 30, 60 e 120 segundos, só quando uma nova tentativa pode resolver: erro 5xx, queda de conexão e tempo esgotado. Recusa da chave, recurso acima do teto e limite de requisições que passou da espera máxima não são repetidos.

​
API da fonte

Todas as chamadas só leem dados. O host da API é https://api.apollo.io. Pela tabela de preços do Apollo, esses endpoints custam 0 crédito. Rate limits. O Apollo limita por time e por endpoint, em três janelas fixas: por minuto, por hora e por dia. No plano Free, são 50 por minuto, 200 por hora e 600 por dia em cada endpoint. Os planos pagos vão até 200 por minuto, e até 400 ou 600 por hora e 2.000 ou 6.000 por dia, conforme o plano. Ao estourar, a API responde 429 com o header retry-after. Uma leitura completa de 50.000 contatos usa 500 chamadas do endpoint de contatos, mais do que a janela de uma hora do plano Free. O conector envia uma chamada por vez, com tempo limite de 120 segundos, e nunca segue redirecionamento. Diante de um erro 429, espera o tempo do retry-after e tenta de novo, enquanto a espera somada da chamada não passar de 1 hora. Um erro 5xx é repetido com recuo que começa em 1 segundo e dobra, em até 5 tentativas. Uma queda de conexão é repetida da mesma forma nas listagens por GET. Nas buscas por POST (contatos, contas e tarefas), quem repete é a tentativa seguinte da leitura do recurso. O teste de conexão usa uma chamada por endpoint, com tempo limite de 10 segundos. Referência oficial: Apollo API, rate limits e Apollo API, authentication

​
Limitações conhecidas

  • Sem permissão por item: todo usuário que pode usar o conector vê tudo o que a API key alcança. Para restringir, limite Quem pode usar este conector.
  • A busca de tarefas do Apollo devolve só tarefas abertas. Uma tarefa concluída sai de tasks na execução seguinte. Chamadas concluídas continuam em phone_calls.
  • Um recurso com 50.000 registros ou mais não é carregado. Os outros recursos seguem normalmente.
  • Ficam de fora sequências, e-mails de sequência, notas, conversas gravadas e a atividade de sequência por contato.
  • Os campos customizados ficam como JSON, identificados pelo id do campo, sem o nome que aparece no Apollo.
  • A cada execução, todo o CRM é relido. Em planos com cota diária pequena, um workspace grande pode esgotar a cota de um endpoint antes de terminar.
  • O telefone de um contato só participa da unificação do Memory quando é de linha pessoal (mobile ou work_direct).
  • Uma conexão Apollo.io por instalação, porque a marcação no Data Catalog é guardada por tipo de conector.
  • Não há conversão de moeda nos valores de deal.

​
Troubleshooting

​
Próximos passos

Data Catalog

Ligue os recursos e as tabelas clean do Apollo.io e marque as colunas com dado pessoal.

Memory

Veja como contatos, contas, deals e usuários entram no grafo e se unificam com os outros CRMs.
O conector não lê variáveis do .env. A API key é informada no Console e fica no cofre de segredos da plataforma, sob o nome APOLLO_API_KEY. Para testar localmente, crie a conexão pelo Console da stack local.