Pular para o guia rápido

Documentação

De um fluxo desenhado a uma chamada em produção.

Do que é feito um fluxo de decisão, como testá-lo e qual API seus sistemas chamam depois que ele entra no ar. Um endpoint, uma chave de API e uma resposta que se explica sozinha.

Guia rápido

Quatro passos até uma decisão que você consegue chamar.

  1. 01

    Monte o fluxo

    Desenhe a decisão no editor — regras, tabelas de decisão, ramificações e etapas de código ligadas em um único grafo. Todo resultado tem um caminho explícito, então dá para acompanhar a lógica sem ler código.

  2. 02

    Teste no Sandbox

    Rode casos representativos pelo rascunho. A trilha mostra o caminho percorrido nó a nó, então você corrige a lógica antes de um cliente encontrá-la — e não depois.

  3. 03

    Publique uma versão

    Publicar torna a versão apta a receber tráfego de produção. Sua integração continua chamando o mesmo endpoint; qual versão atende é uma escolha feita dentro do produto, não um deploy.

  4. 04

    Chame a API

    POST the input to the flow's decide endpoint with your API key. The response carries the output, the version that produced it, and the trace behind it.

API de decisão

Um POST, e o raciocínio volta junto com a resposta.

Requisição
curl -X POST https://api.arborule.com/run/api/v1/flows/YOUR_FLOW_SLUG/decide \
  -H "X-Api-Key: $ARBORULE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": { "first_name": "Grace", "last_name": "Hopper" },
    "metadata": { "grouping_id": "application-4821" }
  }'
Resposta
{
  "decision_id": "01J8ZQ...",
  "status_code": "succeeded",
  "created_at": "2026-07-30T14:02:11Z",
  "environment": "live",
  "grouping_id": "application-4821",
  "duration_ms": 41,
  "input": { "first_name": "Grace", "last_name": "Hopper" },
  "output": { "decision": "approve", "limit": 12000 },
  "trace": [ /* node-by-node record of the path taken */ ]
}

Autenticação

Toda chamada leva um cabeçalho X-Api-Key . As chaves são criadas por workspace e limitadas ao que podem fazer, então uma integração que só decide não consegue editar um fluxo.

Campos da requisição

data
The decision's input, matching the flow version's input schema. Everything your rules read comes from here.
metadata.grouping_id
Seu identificador para o que está sendo decidido — uma proposta, um cliente, uma transação. Mantém chamadas repetidas na mesma versão roteada e as agrupa no histórico.
metadata.version
Opcional. Fixa uma versão publicada pelo nome, em vez de deixar o roteamento de tráfego escolher.
control.async
Opcional. Retorna assim que a execução for aceita, em vez de esperar o resultado.

Endpoints

MétodoCaminhoO que faz
POST/run/api/v1/flows/:slug/decideExecuta a versão publicada de um fluxo em tráfego de produção. Roteado por peso e fixo por grouping_id.
POST/run/api/v1/flows/:slug/sandbox/decideExecuta uma versão rascunho no Sandbox. Mesma requisição e mesma resposta do ambiente de produção, então a chamada que você testa é a que vai para o ar.
GET/run/api/v1/flows/:slug/versionsList the flow's versions and their status, so a caller can pin one by name.
GET/history/api/v1/decisionsPercorre as decisões registradas, filtrando por fluxo, ambiente ou grouping_id.

Cada fluxo também publica um documento OpenAPI 3.1 com seus próprios esquemas de entrada e saída, gerado a partir da versão publicada — assim o código do cliente sai do fluxo, e não copiado à mão de uma página como esta.

Ambientes e versões

Sandbox e Live são o mesmo fluxo em níveis diferentes de confiança.

O Sandbox roda um rascunho; o Live roda uma versão publicada. Os dois recebem o mesmo corpo de requisição e devolvem a mesma resposta, então nada muda na integração quando um fluxo é promovido.

O tráfego de produção é distribuído entre as versões publicadas por peso e mantido fixo por grouping_id, para que a mesma proposta não receba duas respostas diferentes no meio do caminho enquanto uma nova versão ganha tráfego.

  • SandboxVersões rascunho. Mesma requisição, mesma resposta, sem impacto no cliente.
  • LiveSomente versões publicadas. Roteamento por peso, fixo por grouping_id.
  • HistóricoToda execução nos dois ambientes, consultável por fluxo, ambiente ou grouping_id.

Referência de nós

O que você pode colocar no editor.

Decidir

A lógica em si — a parte que o dono da política edita.

  • Regra
  • Tabela de Decisão
  • Matriz 2D
  • Scorecard
  • Divisão
  • Junção
  • Loop
  • Fluxo de Decisão

Buscar e preparar

Traz o que a decisão precisa e deixa no formato certo.

  • Entrada
  • Saída
  • Atribuição
  • Código
  • PostgreSQL
  • Conexão
  • Webhook de Entrada
  • Ler Entidade
  • Criar ou atualizar Entidade

Modelos e agentes

Para quando a decisão pede um julgamento que uma tabela não expressa.

  • IA
  • Agente
  • Modelo de ML

Passar para uma pessoa

Para as decisões que não devem ser automáticas.

  • Revisão Manual
  • Criar Caso
  • Atualizar Caso

Perguntas frequentes

O que os times perguntam antes de integrar.

Como chamo um fluxo de decisão a partir da minha aplicação?

Faça um POST para /run/api/v1/flows/:slug/decide em api.arborule.com, com o cabeçalho X-Api-Key e um corpo JSON com sua entrada dentro de `data`. A resposta traz o id da decisão, o resultado em `output`, o ambiente em que rodou, quanto tempo o motor levou e a trilha nó a nó do caminho percorrido. É uma chamada HTTP comum — não há SDK para adotar nem callback para hospedar no caso síncrono.

Qual a diferença entre os endpoints de Sandbox e de Live?

/run/api/v1/flows/:slug/sandbox/decide executa uma versão rascunho; /run/api/v1/flows/:slug/decide executa uma versão publicada. O corpo da requisição e o formato da resposta são idênticos, então a chamada que você testa é a que vai para o ar — muda apenas qual versão responde e se a execução conta como tráfego de produção. As duas ficam registradas no histórico de decisões, cada uma no seu ambiente.

Como fixo uma decisão em uma versão específica do fluxo?

Set metadata.version to a published version's name. Leave it out and live traffic is routed across published versions by weight, kept sticky per grouping_id so the same application does not get two different answers while a new version is ramping. Pinning is what you want for a replay or a regression test; routing is what you want in production.

Como encontro uma decisão depois que ela rodou?

Toda resposta inclui um decision_id. O GET /history/api/v1/decisions devolve as decisões registradas filtradas por flow_slug, ambiente ou grouping_id, então dá para buscar uma pelo id ou listar tudo o que aconteceu com uma proposta. O registro guarda a entrada, a saída, a versão que a produziu e a trilha — que é exatamente o que uma notificação de recusa ou uma revisão de processo exige.

O que acontece quando a decisão precisa de uma pessoa?

Duas coisas diferentes, e a diferença importa. Um nó de Revisão Manual pausa a execução: a API devolve na hora uma decisão pendente e um caso de revisão, e a mesma execução continua daquele nó assim que alguém responde. Um nó de Criar Caso não pausa nada — o fluxo abre um caso para um revisor e segue devolvendo sua resposta, então nada fica esperando por uma pessoa.

Preciso de um SDK ou de alguma linguagem específica?

Não. A API de decisão é HTTP e JSON, chamada com um cabeçalho de chave de API, então qualquer coisa capaz de fazer uma requisição consegue chamá-la. Cada fluxo também publica um documento OpenAPI 3.1 com seus esquemas de entrada e saída, gerado a partir da versão publicada — então, se você quiser um cliente tipado, gere-o a partir do fluxo em vez de escrevê-lo à mão a partir desta página.

Comece a ler dentro do produto

O resto da documentação fica ao lado do fluxo.

Cada fluxo tem sua própria referência de API, gerada a partir da versão que você publicou. Crie um workspace, monte um fluxo e leia a documentação que ele produz.

Veja quanto custa