Skip to main content
POST
Emissão de Confirmação
Algumas operações da API são disruptivas o suficiente para exigir uma confirmação explícita: elas trocam algo que já está em uso e, se disparadas sem querer, causam uma interrupção. Essas operações exigem o header X-Confirmation-Token e, sem ele, respondem 409 (confirmation_required) trazendo, no próprio corpo do erro, um token pronto para repetir a chamada. Este endpoint existe para quem prefere não depender desse 409: você pede o token antecipadamente, já sabendo qual operação vai confirmar, e envia a chamada original já com o header preenchido. As duas formas produzem exatamente o mesmo tipo de token e são totalmente intercambiáveis.

O token

O confirmation_token retornado é assinado pela própria API. Ele é vinculado ao usuário autenticado, à ação (action), ao recurso (resource) e aos campos enviados em params que definem a mudança: um token emitido para um conjunto de parâmetros não confirma uma chamada com parâmetros diferentes. Ele expira em expires_at, cerca de 5 minutos após a emissão.

Ações registradas

O campo action só aceita ações que a API reconhece como confirmáveis. Cada uma exige um campo diferente em params, que é exatamente o que o token passa a confirmar: Omitir o campo obrigatório de params é um erro de validação 400, de propósito: um token emitido sem ele confirmaria uma mudança vazia e falharia depois, na operação real, com um erro de incompatibilidade difícil de entender.
Este endpoint não verifica se o resource existe nem se pertence a você, de propósito. O token só passa a valer alguma coisa quando a operação que ele confirma é chamada de verdade, e essa operação sempre confere a posse do recurso por conta própria antes de agir. Um token emitido para um recurso de outra conta simplesmente não confirma nada quando usado.

O que isso não é

Essa confirmação não é uma camada de segurança nem um passo de autorização. Quem já tem o token de acesso da sua conta sempre consegue emitir uma confirmação, para qualquer ação registrada. Ela existe para tornar deliberada uma mudança disruptiva que, de outra forma, poderia acontecer por engano, e não para impedir chamadas mal-intencionadas.

Exemplo

Use o confirmation_token retornado no header X-Confirmation-Token da chamada original, dentro dos expires_at retornados junto.

Autorizações

Authorization
string
header
obrigatório

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Corpo

application/json
action
enum<string>
obrigatório

Ação destrutiva registrada que está sendo pré-confirmada. Cada ação exige um campo diferente dentro de params, que descreve exatamente o que muda:

  • instance.migrate_connection: exige params.to, o tipo de conexão de destino (unofficial ou waba)
  • instance.reconnect: exige params.phone_number_id, o ID do número de telefone de destino
Opções disponíveis:
instance.migrate_connection,
instance.reconnect
Exemplo:

"instance.reconnect"

resource
string
obrigatório

ID do recurso ao qual a ação se aplica. Para as ações atualmente registradas, é o ID da instância.

Exemplo:

"ozj35qv418rpmlrb"

params
object

Campos que descrevem a mudança sendo confirmada. Cada ação exige um campo específico aqui (veja action); qualquer outro campo enviado é ignorado. Omitir o campo exigido é um erro de validação, propositalmente: um token emitido sem ele não confirmaria mudança nenhuma.

Resposta

Success

action
string
Exemplo:

"instance.reconnect"

confirmation_token
string

Token de confirmação assinado. Envie-o no header X-Confirmation-Token da chamada que ele confirma.

Exemplo:

"eyJ2IjoxLCJhY3QiOiJpbnN0YW5jZS5yZWNvbm5lY3QifQ.q1w2e3r4t5y6"

expires_at
string<date-time>

Validade do confirmation_token, cerca de 5 minutos após a emissão.

Exemplo:

"2026-08-08T18:35:00.000Z"

resource
string

ID do recurso informado na requisição

Exemplo:

"ozj35qv418rpmlrb"