Changelog

• leadTemperature (ou temperature) precisa ser um número inteiro no POST e no PUT de leads e no filtro do GET /lead. Um texto como "quente" ou um decimal como 2.5 agora responde 400 com leadTemperature must be an integer (antes, o valor quebrava a gravação com 500).
• Número em texto continua aceito: "3" é gravado como 3. null limpa a temperatura.

• O PUT /lead/{id} agora grava apenas os campos documentados em Atualizar Lead. Outros campos do corpo são ignorados, sem erro.

• currency agora aceita qualquer moeda corrente da ISO 4217 (antes, só BRL, USD e EUR), como GBP, JPY, ARS ou CLP, no POST e no PUT de negócios.
• O código é aceito em minúsculas e com espaços nas pontas: "usd" é gravado como USD.
• Código desconhecido continua respondendo 400, agora com a mensagem Invalid currency. Use an ISO 4217 code, such as BRL, USD or EUR.
• As respostas trazem sempre o código da moeda (negócio sem moeda gravada vem como BRL), e o value está sempre nessa moeda: mudar a currency não converte o valor.

{ "title": "Contrato anual", "stageId": "ID_DA_ETAPA", "value": 1500, "currency": "usd" }

• GET /lead e GET /lead/{id} passam a trazer country, state, city, neighborhood, streetAddress, number, complement, zipCode e description (antes, só a resposta do POST trazia esses campos). São campos novos: nada mudou nos que já existiam.
• POST /lead e PUT /lead/{id} aceitam country com o nome do país em português. Um nome da lista de países da plataforma é gravado com a grafia dela, sem diferenciar maiúsculas e acentos ("brasil" vira Brasil, "estados unidos" vira Estados Unidos); outro texto é gravado como veio.

{ "name": "Maria Souza", "city": "Lisboa", "country": "portugal" }

Veja Criar Lead, Atualizar Lead, Obter Lead e Atualizar Negócio.

• Os administradores agora escolhem a ordem dos setores em Mensagens > Ordenar setores, e o GET /chat-sector segue essa ordem (antes, do mais recente para o mais antigo). Setores que nunca foram reordenados ficam na ordem de criação, do mais antigo para o mais recente.
• Cada setor traz o campo novo position (número inteiro, menor primeiro).

Veja Listar Setores do Chat.

A API e os webhooks agora estão disponíveis a partir do plano Equipe (antes, só nos planos Pro e Escala). Nada muda para quem já usa.

Cada pipeline agora tem uma etapa de ganho e, se quiser, uma etapa de perdido (em Pipelines > Etapas de ganho e perdido, na plataforma). O status do negócio acompanha a etapa, e a API segue a mesma regra:

• Negócio criado numa etapa de ganho (POST) já nasce won, e numa etapa de perdido já nasce lost, mesmo que o corpo traga outro status.
• status won ou lost com uma etapa em andamento leva o negócio para a primeira etapa de ganho ou de perdido do pipeline. No PUT, mover para uma etapa de ganho ou de perdido muda o status, e reabrir (open) leva de volta para a última etapa em andamento.
• Todo negócio ganho tem a data do ganho (wonAt) e todo perdido a data da perda (lostAt). Se você não informar, vale o momento da criação ou da alteração. Para registrar uma venda que já aconteceu, envie a data real: "wonAt": "2026-07-15". Datas no futuro respondem 400.
• Enviar o mesmo status de novo não muda a data. No PUT, wonAt/lostAt também corrigem a data de um negócio já ganho ou perdido.

• currency (BRL, USD ou EUR; padrão BRL) no POST, no PUT e nas respostas. Outro valor responde 400.
• As respostas trazem lossReasonId (o motivo da perda escolhido na plataforma) e lossNote (a observação da perda). Os dois podem ser enviados ao marcar o negócio como perdido; um lossReasonId que não é da conta responde 404.
• GET, GET /{id} e a resposta do POST passam a trazer wonAt e lostAt de verdade (antes vinham ausentes).

Veja Criar Negócio e Atualizar Negócio.

Os campos personalizados que sua conta cria em Leads > Campos agora aparecem e podem ser gravados pela API, pela chave do campo (e não pelo id interno).

• GET /lead e GET /lead/{id}, e a resposta do POST /lead, trazem customFields: um objeto { "<chave>": valor } só com os campos ativos e preenchidos. Campos de seleção trazem o nome da opção e os de seleção múltipla uma lista de nomes. Sem nenhum valor, vem {}.
• POST /lead e PUT /lead/{id} aceitam customFields no corpo. Seleção aceita o nome ou o id da opção; números, 1500 ou 1.500,50; datas, 2026-03-15 ou 15/03/2026; Sim/Não, true/false ou sim/não.
• No PUT, null ou texto vazio limpa o campo, e os campos que você não enviar ficam como estão. Campos obrigatórios da conta não são exigidos pela API.

Nos negócios (/account-crm-pipeline-deal) vale o mesmo, com uma diferença: os campos de negócio são por pipeline.

• GET, GET /{id} e a resposta do POST trazem customFields só com os campos do pipeline do negócio.
• POST e PUT /{id} aceitam customFields pela chave. Só valem os campos do pipeline da etapa em que o negócio fica (no PUT, a etapa de destino quando o negócio muda de etapa).

Veja Criar Lead, Atualizar Lead, Listar Leads, Obter Lead e Criar Negócio.

Um lead pode ser a empresa de um grupo ou uma das pessoas dele, cada uma com o seu cargo. GET /lead e GET /lead/{id} passam a aceitar ?include=groups, que acrescenta dois campos a cada lead:

• groups: os grupos de que o lead é uma das pessoas, com id, name e o role (cargo) dele em cada um;
• company: o grupo de que o lead é a empresa, com id, name e peopleCount, ou null.

Sem o parâmetro, a resposta continua igual à de antes: a sua integração atual não muda.

Veja Listar Leads e Obter Lead.

Em POST /lead e PUT /lead/{id}, o createdByAccountUserId informado também precisa ser o id do vínculo de um membro da sua conta (use Listar Membros da Conta). Se não for, a API responde 404 e não grava nada, como já acontece com leadOwner.

Excluir um lead apaga também a foto dele, e excluir um negócio, uma etapa ou um pipeline apaga os arquivos anexados aos negócios afetados. O formato das respostas não muda.

O POST /lead não cria mais um lead novo quando a conta já tem um lead com o mesmo CPF/CNPJ, telefone ou e-mail. Nesse caso, a API:

• devolve o lead existente, com o mesmo formato de resposta e o mesmo status 201;
• preenche nele só os campos que estavam vazios, sem sobrescrever o que já estava preenchido.

A busca verifica primeiro o CPF/CNPJ, depois o telefone e por fim o e-mail. O telefone é comparado sem DDI e sem formatação, então 5547999999999, +55 (47) 99999-9999 e 47999999999 são o mesmo número. No e-mail, maiúsculas e minúsculas não fazem diferença.

Veja Criar Lead.

A conta vem sempre do seu token. Um accountId enviado no corpo é ignorado. Qualquer id que você informar precisa pertencer à conta do token; se não pertencer, a API responde 404 e não grava nada:

Nos campos leadOwner, dealOwner e conversationOwnerId, use o id do vínculo devolvido por Listar Membros da Conta, e não o User.id. Antes desta versão, um id inválido nesses campos devolvia 500; agora devolve 404.

Também passam a responder 404 quando o registro é de outra conta:

• GET, PUT e DELETE /account-crm-pipeline-stage/{id};
• PUT /account-external-conversation/{id}/update-status.

E mais dois ajustes:

• GET /account-crm-pipeline-stage sem pipelineId devolve só as etapas dos pipelines da sua conta.
• Em PUT /category/{id}, os campos id, accountId, createdAt e updatedAt do corpo são ignorados.

Em POST /whatsapp/send-message e POST /instagram/send-message, o senderId precisa ser de um membro da conta. Você pode enviar o User.id ou o id do vínculo (os dois vêm em Listar Membros da Conta).

Um senderId que não é de um membro da conta responde 404 e a mensagem não é enviada. Omita o campo para registrar a mensagem como enviada por IA/automação.

• DELETE /lead/label/assign responde 404 quando o lead ou a etiqueta não existem na conta. Antes, respondia 200 mesmo sem ter o que remover.
• POST /lead/label cria sempre etiquetas de lead. Um labelType diferente enviado no corpo é ignorado.

Um token de API desativado recebe 401 em todas as rotas.