Skip to main content
A API nunca cria leads como efeito colateral de um envio: se o destinatário não existe, o envio falha com 404 lead_not_found. Criar lead é sempre uma ação explícita sua.

Buscar um lead

Por telefone (aceita E.164 ou apenas dígitos):
Em query string, o + precisa ser codificado como %2B — um + cru vira espaço. Alternativa: mande só os dígitos (?phone=5511999999999).
Por id (o lead_... retornado na criação):
As duas formas retornam o mesmo recurso:
Números brasileiros: a busca por telefone testa automaticamente a variação do nono dígito, então funciona com ou sem o 9 após o DDD.

Criar um lead

Campos: O lead criado entra na primeira etapa do funil da empresa. Se a empresa não tem funil configurado no painel, a resposta é 422 funnel_not_configured.

Telefone duplicado

Se já existe um lead com esse telefone na sua empresa, a resposta é 409 lead_already_exists. Nesse caso, recupere o lead existente com a busca por telefone — e envie a mensagem normalmente, já que o envio só precisa do telefone em to.

Fluxo recomendado: garantir lead antes do envio

1

Busque pelo telefone

GET /v1/leads?phone=.... Se retornar 200, o lead existe — siga para o envio.
2

Se 404, crie o lead

POST /v1/leads com nome e telefone. Trate 409 como sucesso (outra automação pode ter criado o lead entre as duas chamadas).
3

Envie a mensagem

POST /v1/whatsapp/messages com o telefone em to.

Editando um lead

Atualize dados cadastrais com PATCH /v1/leads/{id} — envie só o que mudou. Campo omitido fica como está; null explícito limpa o campo.
Campos editáveis: name, email, notes, source, channel, entry_point, utm_*, document + document_type (CPF ou CNPJ — enviando só document, o tipo é inferido pelo tamanho), cep, address, address_number, address_complement, neighborhood, city, state, country.
Telefone e etapa do funil não são editáveis por aqui. O telefone é a identidade WhatsApp do lead. A etapa muda pelo endpoint próprio abaixo — que registra o histórico da transição.

Movendo o lead de etapa

Primeiro, descubra as etapas da sua empresa (os ids são estáveis — sobrevivem a renomear a etapa no painel):
Depois, mova com PUT /v1/leads/{id}/stage:
  • Idempotente: mover para a etapa em que o lead já está retorna 200 com changed: false — sem log duplicado. Seguro para retries.
  • Histórico completo: a transição fica registrada no painel (origem API), com o reason como observação. Pular etapas registra as intermediárias automaticamente.
  • stage_id de outra empresa retorna 404 stage_not_found — as etapas são escopadas pela sua chave.

Sincronizar leads alterados

Para manter um sistema externo (CRM, dashboard, planilha) em dia com os leads da Superlead, peça só o que mudou desde a última sincronização com GET /v1/leads?updated_since=....
Quer saber na hora, sem perguntar? Assine os webhooks de lead (lead.created, lead.updated, lead.deleted) e use esta listagem como reconciliação periódica.
Não consulte lead a lead (GET /v1/leads/{id} em laço) para descobrir o que mudou. Com milhares de leads, isso esgota o rate limit da chave e fica lento — a listagem traz até 100 leads alterados por requisição.
  • Cada item é o mesmo recurso de GET /v1/leads/{id}, com updated_at.
  • A lista vem em ordem crescente de updated_at.
  • updated_at muda em qualquer alteração do lead — criação, cadastro, etapa do funil, atribuição — e também quando o lead manda mensagem. Vem sempre em UTC, com 6 casas decimais.
  • updated_since é inclusivo e exige fuso: use Z (UTC) ou um deslocamento como -03:00. Com deslocamento positivo, codifique o + como %2B.
  • limit vai de 1 a 100 (padrão 50).

Paginação

Enquanto has_more for true, repita a chamada adicionando starting_after com o next_cursor recebido:
O cursor é opaco: envie exatamente o valor recebido. Ele garante que nenhum lead se repete nem fica de fora entre as páginas, mesmo quando vários leads mudam no mesmo instante. Quando has_more é false, next_cursor vem null.

Fluxo recomendado

1

Primeira sincronização: traga tudo

Use updated_since com uma data antiga (por exemplo 2000-01-01T00:00:00Z) e limit=100. Percorra as páginas até has_more: false e guarde o maior updated_at que apareceu.
2

Próximas sincronizações: só o que mudou

A cada ciclo (por exemplo, a cada 15 minutos), use como updated_since o maior updated_at guardado menos 5 minutos. Percorra as páginas e atualize o maior updated_at.
3

Grave pelo id

Insira ou atualize cada lead pelo id (lead_...). A sobreposição de 5 minutos traz de volta alguns leads que você já tem — gravando pelo id, isso é inofensivo.
Por que voltar 5 minutos: updated_at registra o momento da alteração, e uma alteração pode ficar visível na API alguns instantes depois desse momento. Sem a sobreposição, ela poderia cair antes do ponto em que você parou e nunca ser lida.
Exemplo em JavaScript:
Leads excluídos não aparecem na listagem. Para refletir exclusões, assine o webhook lead.deleted. Sem webhook, faça de tempos em tempos (por exemplo, uma vez por semana) uma sincronização completa, com updated_since antigo: os leads que você tem e que não vierem nela foram excluídos.