Skip to main content
Envia para análise o cadastro que já foi declarado na organização. Não recebe corpo: tudo o que vai para a análise foi gravado antes com POST /v1/organizations/{id}. Chame este endpoint quando requirements.missing estiver vazio. Enquanto faltar qualquer campo, a resposta é 400 com code: "requirements_incomplete" e a lista do que falta. O envio é assíncrono: a resposta 200 confirma que o cadastro entrou na fila de análise (activation_status: "in_review"), não que foi aprovado. O resultado chega por organization.updated.

Autenticação

O {id} da URL identifica a organização. Com chave de plataforma, a API confirma que esse org_* tem uma conexão ativa com a plataforma da chave.
Não envie o header Organization. Ele não participa desta operação e não corrige um 404. Confira o ID da URL e o vínculo da organização.

Parâmetros de caminho

string
required
ID da organização (org_*).

Corpo da requisição

Nenhum parâmetro. Se você enviar um corpo, ele precisa ser um objeto JSON válido — o conteúdo é ignorado.

Comportamento

  • Idempotente por estado. Organização já in_review ou active responde 200 com o objeto atual, sem reenviar nada e sem abrir uma análise nova. Repetir a chamada por timeout é seguro.
  • Validação antes da fila. O envio só entra na fila quando o cadastro está completo e consistente. Falta de campo vira 400 requirements_incomplete, com param apontando o primeiro caminho de requirements.missing.
  • Reenvio após reprovação. Em disabled com requirements.disabled_reason: null, corrija os campos apontados em requirements.missing com POST /v1/organizations/{id} e chame /submit de novo — mesma organização, mesmo org_*. Com disabled_reason preenchido não há caminho de autoatendimento; encaminhe ao suporte.
  • Modo de teste. Funciona com credencial de teste; o desfecho é escolhido pelo CPF/CNPJ da organização. Veja a tabela em Ativação por API.

Resposta

200 OK com o objeto organization completo. activation_submitted_at carimba o envio e activation_status passa para in_review. requirements.pending_verification começa vazio e passa a listar o que está sendo verificado conforme a análise avança — releia a organização (ou espere o próximo organization.updated) para acompanhar.

Erros

Antes de enviar, faça GET /v1/organizations/{id} e confirme que requirements.missing está vazio. Depois do 200, acompanhe organization.updated; não trate a resposta do submit como aprovação.

Acompanhando o resultado

A análise é assíncrona. O veredito chega por organization.updated:
  • Aprovadoactivation_status: "active" e requirements todo vazio.
  • Reprovadoactivation_status: "disabled", requirements.errors com o motivo e requirements.missing com o que dá para corrigir.
  • Falha do envio → a organização volta para not_submitted, activation_submitted_at volta para null e requirements.errors explica o que impediu o envio. Corrija e chame /submit de novo.
O passo a passo completo está em Ativação por API; a leitura de requirements está em Requisitos de ativação.