Pular para o conteúdo
BetaDocumentação em validação contínua. Comportamento descrito pode divergir do servidor — abra um chamado no app se algo não bater.
Inbound

Webhooks de entrada

Receba dados externos no MIX sem precisar usar a API REST. Útil para conectar formulários, Zapier, n8n, ou qualquer backend que já chame webhooks pra ferramentas tipo "mais um destino".

Quando usar

  • Formulários no seu site que não rodam em landing pages do MIX.
  • Zapier / Make / n8n — qualquer ferramenta de automação no-code que dispara webhook como ação.
  • Backend legado que já posta pra Slack/HubSpot e você quer adicionar o MIX sem refatorar.
Informação
Diferença vs API REST
Inbound webhooks aceitam qualquer payload e mapeiam no servidor. A API REST exige payload bem formado. Use inbound quando você não controla o formato; API REST quando você controla.

Criar um inbound webhook

  1. No app, vá em Configurações → Webhooks → Entrada.
  2. Clique em Novo webhook de entrada.
  3. Defina:
    • Nome: ex.: "Formulário lead-magnet".
    • Tipo de objeto: person ou deal (companies não são suportados como destino direto na v1 atual — crie uma person e o sistema linka via domínio).
    • Mapeamento de campos: pra cada campo do payload externo, qual campo do MIX ele alimenta.
    • Estratégia de dedup: email (se vier um e-mail já cadastrado, faz UPDATE em vez de criar duplicata) ou none.
    • Ações pós-recepção: atribuir owner, adicionar tags, criar deal automaticamente.
  4. Copie a URL gerada. Formato:
    text
    https://api.usemix.app/webhooks/in/<token>

Enviar dados

POST com JSON. Não há autenticação por header — o token na URL é a credencial.

cURL
curl -X POST https://api.usemix.app/webhooks/in/<token> \
  -H "Content-Type: application/json" \
  -d '{
    "nome_completo": "João Pereira",
    "email": "joao@startup.com.br",
    "empresa": "Startup Inc"
  }'

Se o mapeamento bate (campo email mapeado para primaryEmail), uma pessoa nova é criada e você recebe 201:

JSON
{ "ok": true, "personId": "1f0c87e8-..." }

Exemplo de payload externo

Imagine que seu formulário envia:

seu-formulario.json
{
  "nome_completo": "João Pereira",
  "email": "joao@startup.com.br",
  "telefone": "+5511988887777",
  "empresa": "Startup Inc",
  "interesse": "implementação completa",
  "utm_source": "google",
  "utm_campaign": "lead-magnet-q2"
}

E você configurou o mapeamento como:

field mapping (config no app)
{
  "fullName": "{{nome_completo}}",
  "primaryEmail": "{{email}}",
  "primaryPhone": "{{telefone}}",
  "leadSource": "zapier",
  "customFields": {
    "interesse_inicial": "{{interesse}}",
    "utm_source": "{{utm_source}}",
    "utm_campaign": "{{utm_campaign}}"
  }
}

O resultado é uma pessoa criada com fullName: "João Pereira", primaryEmail: "joao@startup.com.br", e os campos de UTM viram custom fields. Sem código.

Deduplicação

Estratégias suportadas em Configurações → Webhooks de entrada:

  • email — se já existe pessoa com esse primaryEmail, faz UPDATE merge com os campos novos. Recomendado para 99% dos casos.
  • phone — mesmo, mas por primaryPhone.
  • composite — combinação de campos (ex.: e-mail + nome). Configurada no app web.
  • none — sempre cria duplicata. Útil quando você quer rastrear cada submit (ex.: histórico de submissões).

Erros comuns

  • 404 not_found: token revogado ou inválido.
  • 422 validation_error: payload não bate com o mapeamento (campo obrigatório ausente após mapping). Veja details.field.
  • 429: o limite global de 300 req/min se aplica também a inbound.
Atenção
Token na URL é secreto
Apesar de ser parte da URL, trate o token como credencial. Se vazar (logs públicos, erro no GitHub), revogue em Configurações.

A gente usa cookies pra entender o que funciona e o que não funciona aqui. Sem terceiros — dado fica conosco. Política.