Avisar o ERP quando o pedido é aprovado

O pedido de compra corre na TAI: alguém abre, a diretoria aprova. Quando chega à fase Aprovado, o ERP precisa criar o pedido no sistema de suprimentos — e a TAI precisa saber o número que o ERP gerou. Nesta jornada, a automação do fluxo chama o ERP com os campos do card, e o ERP devolve o número e conclui o card pela API. O card que fica parado é o pedido que não chegou.


Quando usar	Uma etapa do processo precisa disparar algo em outro sistema e receber o resultado
Porta	Automação/webhook (TAI → ERP) · REST (ERP → TAI)
Você vai precisar	módulo `GESTAO_PROCESSOS`; quem configura precisa gerenciar o fluxo; para a volta, permissão `PROCESSO` e acesso de Contribuidor ao fluxo; JWT de um usuário de integração vinculado a um colaborador

Como funciona

Solicitação ──► Aprovação ──(aprovado)──► Aprovado ──► Pedido no ERP (fase de conclusão)
                                             │
              automação "Entrada na Fase: Aprovado"
                                             │  Webhook POST, corpo com {{campo.*}}, assinado
                                             │  (falhou? novas tentativas por ~21 h)
                                             ▼
                                            ERP ── 2xx imediato, processa na fila dele
                                             │
   POST /card-field-value/by-card/{id}/batch  { "numero_pedido_erp": "PC-4471" }
   POST /card/{id}/mover/{faseConcluida}      ──► card concluído

O card é o que torna esta jornada um acompanhamento: quem olha o fluxo vê o pedido parado em Aprovado até o ERP responder. Se o seu sistema só precisa saber dos cards, sem devolver nada, o caminho é mais curto — veja Variações.

Passo a passo

Monte o fluxo. Em Processos → Fluxos, um fluxo “Compras” com as fases Solicitação, Aprovação (com Requer Aprovação e os aprovadores — veja Aprovações), Aprovado e Pedido no ERP (marcada como Fase de Conclusão). Na aba Campos, crie os campos e anote os identificadores:

Campo	Identificador	Tipo
Descrição	`descricao`	Texto longo
Valor total	`valor_total`	Moeda
Centro de custo	`centro_custo`	Centro de custo
Fornecedor sugerido	`fornecedor`	Texto
Nº do pedido no ERP	`numero_pedido_erp`	Texto — quem preenche é o ERP

Crie a automação. Na configuração do fluxo, aba Automações → Nova Automação:

Gatilho: Entrada na Fase, fase Aprovado;
Ação: Webhook (Enviar para outro sistema), com:

Campo	Valor
Endereço do outro sistema	`https://erp.suaempresa.com.br/integracoes/tai/pedidos`
Método (em Avançado)	`POST`
Cabeçalhos (em Avançado)	nome `Authorization`, valor `Bearer seu-token` — guardado cifrado
Conteúdo enviado (em Avançado)	o modelo abaixo
Assinar o envio (em Avançado)	ligado — copie o segredo gerado para o ERP; ele não aparece de novo

{
  "cardId": "{{card.id}}",
  "numero": "{{card.numero}}",
  "descricao": "{{campo.descricao}}",
  "valor": "{{campo.valor_total}}",
  "centroCustoId": "{{campo.centro_custo}}",
  "fornecedor": "{{campo.fornecedor}}",
  "solicitante": "{{criador.email}}",
  "abertoEm": "{{card.dataCriacao}}"
}

Todas as variáveis estão em Automações de processos. Antes de ligar, o botão Testar confere num card se as condições casam, sem executar nada.

Receba no ERP. O endpoint do ERP confere a assinatura do cabeçalho X-Tai-Assinatura com o segredo (ou o token do cabeçalho Authorization), grava o pedido numa fila própria e responde 200 na hora. A TAI espera no máximo 30 segundos e não segue redirecionamento. Falha de rede, 5xx, 408, 425 ou 429 entram em novas tentativas sozinhas — 1 min, 5 min, 30 min, 2 h, 6 h e 12 h —; outro 4xx desiste na hora. As regras estão em Entregas e novas tentativas.

Cada envio leva X-Tai-Entrega (igual em todas as tentativas da mesma entrega) e X-Tai-Tentativa. Use X-Tai-Entrega para não processar a mesma entrega duas vezes, e cardId como chave do pedido: se o mesmo card chegar por outra execução (um reenvio manual, uma reconciliação), o ERP não cria dois pedidos.

Devolva o resultado ao card. Quando o pedido existe no ERP, grave o número pelo identificador do campo e mova o card para a fase de conclusão:

curl -s -X POST https://api.taitecnologia.com/card-field-value/by-card/90412/batch \
  -H "Authorization: Bearer $TAI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "numero_pedido_erp": "PC-4471" }'

curl -s -X POST "https://api.taitecnologia.com/card/90412/mover/66?motivo=Pedido%20PC-4471%20criado%20no%20ERP" \
  -H "Authorization: Bearer $TAI_TOKEN"

O card fica concluído, com o número do ERP e o motivo no histórico. Se o ERP recusar o pedido, registre o motivo num comentário (POST /card-comment) e deixe o card em Aprovado para alguém tratar.

Acompanhe as execuções. Cada disparo fica registrado no card:
Terminal window
```
curl -s https://api.taitecnologia.com/automation/execution/by-card/90412 \
  -H "Authorization: Bearer $TAI_TOKEN"
```
status é SUCCESS, FAILED ou SKIPPED (condições não atendidas); acoesLog diz o que cada ação fez, inclusive o status HTTP que o ERP respondeu e o número da entrega. Quando a primeira tentativa falha, a execução fica com a falha e o motivo em mensagemErro, com a hora da próxima tentativa — a entrega continua viva e segue sozinha. Na tela, o mesmo aparece na Linha do tempo do card, e cada entrega, com o que foi enviado e o que o ERP respondeu, em Processos › Central de Automações › Webhooks › Entregas.

Reenviar e reconciliar

As novas tentativas cobrem quedas de horas. Para o resto:

Reenviar uma entrega: em Processos › Central de Automações › Webhooks › Entregas, Reenviar põe a mesma entrega de volta na fila, com o mesmo X-Tai-Entrega — útil depois de uma entrega Não entregue.
Rodar a automação de novo num card: POST /automation/{automationId}/executar/{cardId} roda a automação na hora, ignorando as condições — é uma entrega nova. A resposta (202) traz o id da execução; acompanhe em GET /automation/execution/{executionId}.
Achar o que não chegou: os cards parados em Aprovado são os pedidos que o ERP não concluiu. Uma rotina do ERP pode listá-los e processá-los:
Terminal window
```
curl -s "https://api.taitecnologia.com/card/by-phase/65/page?page=0&size=100" \
  -H "Authorization: Bearer $TAI_TOKEN"
```
Para os valores de cada card, GET /card-field-value/by-card/{cardId} — cada item traz fieldIdentificador e o valor no campo do tipo (valorTexto, valorNumero, valorData…).

Variações

Avisar em vez de integrar. Troque o Webhook por Notificar ou Enviar Email — o resto da jornada é igual.
Só pedidos acima de um valor. Acrescente uma condição na automação: campo valor_total, operador maior que, valor 10000.
Só saber dos cards, sem devolver nada. Se o ERP (ou o BI) só precisa saber o que acontece com os cards, assine os eventos de Processos num webhook — sem automação no fluxo. Um card é aprovado (CARD_APROVADO) sai a cada decisão “aprovado” numa fase de aprovação; Um card muda de fase (CARD_MOVIDO_FASE), a cada movimento:
```
{
  "id": "evt_51877",
  "tipo": "CARD_MOVIDO_FASE",
  "descricao": "Um card muda de fase",
  "versao": 1,
  "ocorridoEm": "2026-10-06T14:32:08.512Z",
  "empresa": { "id": 12, "nome": "Sua Empresa Ltda" },
  "dados": {
    "cardId": 90412,
    "numero": 1287,
    "pipeId": 14,
    "pipeNome": "Compras",
    "faseId": 65,
    "faseNome": "Aprovado",
    "faseOrigemNome": "Aprovação",
    "responsavelId": 88,
    "criadorId": 1043
  }
}
```
Os eventos de card valem para todos os fluxos: filtre por pipeId no seu lado. Os valores dos campos não vão em dados — marque Enviar também o registro completo ou leia GET /card-field-value/by-card/{cardId}. Também existem Um card é aberto num fluxo (CARD_CRIADO), concluído (CARD_CONCLUIDO), cancelado (CARD_CANCELADO) e reprovado (CARD_REPROVADO) — veja o catálogo.
Formato próprio. Para mandar o evento num corpo que o seu sistema já entende, use um fluxo automatizado com o evento e o bloco Chamar outro sistema — para ficar só com os cards de um quadro, filtre pipeId em Só quando ou use a automação do próprio quadro, como nesta jornada. Veja Da TAI para o seu sistema.
Começar de outro módulo. Se o fato que dispara a integração não nasce num fluxo (uma admissão, uma conta vencida) mas precisa deste mesmo acompanhamento, crie no fluxo uma automação com o gatilho Quando acontecer algo na plataforma, no modo Abrir um card neste fluxo, e a ação Webhook — ela roda no card novo. Veja Fluxo que ouve o evento.

Pelo seu agente de IA

“Quais pedidos de Compras estão aprovados mas ainda sem número do ERP?”

É leitura: o agente filtra os cards da fase e confere o campo. Gravar o número ou mover o card pelo agente são escritas, com aprovação no seu cliente de IA.

Cuidados

Variáveis entram como texto, sem escape. Um campo com aspas ou quebra de linha pode quebrar o JSON do corpo. Para textos livres, mande só {{card.id}} e busque o resto pela API (GET /card/{id}), ou trate o corpo recebido com tolerância.
Campo vazio não é substituído. Se o card não tem valor no campo, o texto {{campo.fornecedor}} vai literal no corpo. Confira no ERP antes de usar o valor.
Formato dos valores: números saem como o decimal do sistema (12500.0 — e, a partir de 10 milhões, em notação científica, como 1.25E7); datas como dd/MM/yyyy HH:mm; campos de colaborador, departamento e centro de custo saem como id.
Laços: a gravação do passo 4 dispara as automações de Campo Alterado, e o movimento dispara Entrada na Fase da fase final. Não aponte uma delas de volta para o mesmo webhook.
Mover exige a fase certa: a fase com destinos permitidos recusa o movimento para outra (400), e a fase de conclusão precisa estar marcada para o card contar como concluído.
URL: só https://, endereço público, sem usuário e senha na URL. A URL é validada ao salvar a automação.

Referência gerada do contrato da API em 30 de outubro de 2026. taitecnologia.com · Termos de uso · Privacidade