Skip to main content

Distribuir um atendimento para um vendedor via n8n

Uma equipe de vendas recebe atendimentos novos e quer distribuí-los entre os vendedores automaticamente (por sorteio, por rodízio ou por uma regra, ex.: cliente de São Paulo vai para o vendedor X). Esta receita mostra como fazer isso com um fluxo no n8n chamando a API v3.

Esta receita usa a API v3, a versão atual. Se você vem da v2, comece por O que a API v3 faz e como começar.

Objetivo

Definir a equipe e o responsável de um atendimento numa única chamada, a partir de um fluxo externo.

Pré-requisitos

  • Token de API com escopo conversations:write: veja tokens-apiGerar tokens de API para integrações.
  • Um fluxo no n8n (ou Make) já recebendo eventos do AtendeBot, com a assinatura no formato 3, que é o padrão das assinaturas novas, tanto pela tela de Ajustes (API e webhooks → Webhooks: no diálogo da assinatura, "Formato do payload" em v3, e o botão { } ao lado de cada evento abre o envelope de exemplo) quanto por POST /public/v3/webhooks ({ "name": ..., "url": ..., "events": [{ "name": "message.received" }] }). Assinatura antiga na v2: edite-a e troque para v3 (o que é um webhook: Configurar webhooks para sistemas externos).
  • Os ids da equipe e dos vendedores que participam do rodízio.

Tempo estimado

10 minutos.

Caminho de acesso

Chamada direta à API: não há tela equivalente no AtendeBot para redistribuição vinda de fora.

Passo a passo

  1. No n8n, capture o id da conversa a partir do evento que dispara o fluxo: numa assinatura criada pela v3, o webhook message.received traz data.conversation.id (e a conversa já carregada em data.conversation, com assignee e team atuais).

  2. Escolha o vendedor (sorteio, rodízio ou regra num nó Function/Code) e monte team_id e assignee_id.

  3. Adicione um nó HTTP Request com PATCH para /public/v3/conversations/{id}, enviando team e assignee no mesmo corpo:

    {
  "parameters": {
    "method": "PATCH",
    "url": "https://api.atende.bot/public/v3/conversations/{{ $json.conversation_id }}",
    "authentication": "genericCredentialType",
    "genericAuthType": "httpBearerAuth",
    "sendBody": true,
    "specifyBody": "json",
    "jsonBody": "={{ JSON.stringify({ team: $json.team_id, assignee: $json.assignee_id }) }}",
    "options": {}
  },
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2,
  "name": "Distribuir atendimento",
  "credentials": {
    "httpBearerAuth": { "id": "1", "name": "AtendeBot API" }
  }
}

    Crie a credencial HTTP Bearer Auth do n8n com o token de API antes de importar o nó.

  4. O mesmo em cURL, para testar antes de montar o fluxo:

    curl -X PATCH https://api.atende.bot/public/v3/conversations/CONVERSATION_ID \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "team": "TEAM_ID", "assignee": "ASSIGNEE_ID" }'

Na v2, trocar de equipe (PUT /transfer) zerava o responsável, e por isso a integração precisava de dois nós. Na v3 os dois campos são aplicados juntos num único PATCH, e team sozinho não mexe no responsável. Migrando da v2: se seu fluxo fazia /transfer e depois /assignee, mande team e assignee no mesmo corpo, como acima; use "assignee": null só quando a intenção é devolver a conversa para a fila, pois zerar numa chamada e atribuir em outra grava duas transferências na trilha e dispara dois conversation.updated.

Resultado esperado

200 com a conversa atualizada; team e assignee voltam como objetos { id, name }.

Erros comuns

  • Sintoma: 404 ao enviar team ou assignee. Solução: o id não existe ou é de outro tenant.
  • Sintoma: o responsável não muda ao trocar só a equipe. Solução: comportamento esperado, envie assignee (ou assignee: null) junto de team.

Artigos relacionados