API

O bloco API faz uma request HTTP a uma URL e retorna a resposta. Use para chamar qualquer REST API: buscar dados, criar um registro ou disparar um endpoint externo.

Configuração

URL

O endpoint a chamar. Digite uma URL estática, ou insira uma connection tag para montá-la a partir de uma saída anterior, como https://api.example.com/users/<start.userId>.

Method

O método HTTP: GET, POST, PUT, DELETE ou PATCH. O padrão é GET.

Query Params

Pares chave-valor anexados à URL como query string. apiKey e limit viram ?apiKey=…&limit=10.

Headers de request chave-valor, como Content-Type: application/json ou Authorization: Bearer <secret>. Headers padrão como User-Agent e Accept são adicionados automaticamente, e seus valores os sobrescrevem.

Body

O payload da request para POST, PUT e PATCH, enviado como JSON. Digite direto, ou puxe de uma saída anterior com uma connection tag.

Advanced

Timeout (ms). Quanto tempo esperar antes de desistir. O padrão é 300000 (5 minutos), até 600000 (10 minutos).
Retries. Número de tentativas em timeouts, respostas 429 e erros 5xx. O padrão é 0.
Retry delay / Max retry delay (ms). Os limites de exponential backoff usados entre retries.
Retry non-idempotent methods. Desligado por padrão, então POST e PATCH não são retentados, o que evita escritas duplicadas. Ligue só quando uma request repetida for segura.

Saídas

Depois que a request termina, blocos posteriores leem o resultado pelo nome:

Saída	O que é
`<api.data>`	O body da resposta, parseado como objeto para JSON ou retornado como texto caso contrário
`<api.status>`	O código de status HTTP, como `200` ou `404`
`<api.headers>`	Os headers da resposta, como objeto

Faça branch no resultado lendo <api.status> em um bloco Condition.

Exemplo

Um workflow que chama um endpoint HTTP e resume a resposta:

O bloco API monta a URL a partir da entrada do Start, busca os dados, e o Agent lê a resposta como <api.data>.

Boas práticas

Mantenha secrets em variáveis de ambiente. Referencie-as com {{VAR}} na URL ou nos headers; nunca hardcode keys.
Trate falhas. Leia <api.status> e faça branch com um Condition, ou conecte o error path para falhas de rede e timeouts.
Configure retries para endpoints instáveis. Use as configurações de retry em Advanced para chamadas idempotentes. Deixe POST e PATCH desligados a menos que uma request repetida seja segura.
Referencie só o campo de que precisa. Puxe <api.data.id> em vez de todo o <api.data> quando a resposta for grande.

Common Questions

O timeout padrão é 300.000 milissegundos (5 minutos). Você pode configurá-lo até o máximo de 600.000 milissegundos (10 minutos) nas configurações Advanced do bloco.

Retries são tentados para falhas de rede e conexão, timeouts, respostas de rate-limit (HTTP 429) e erros de servidor (5xx). Erros de cliente como 400 ou 404 não são retentados.

Retries usam exponential backoff a partir do retry delay configurado (padrão 500ms). Cada retry seguinte dobra o delay, até o máximo retry delay (padrão 30.000ms).

Não. POST e PATCH não são idempotentes, então retries ficam desabilitados por padrão para evitar criar recursos duplicados. Você pode habilitar retries com o toggle 'Retry non-idempotent methods' em Advanced, mas saiba que isso pode causar requests duplicadas.

Headers padrão como User-Agent, Accept e Cache-Control são adicionados automaticamente. Qualquer header customizado que você configurar é mesclado com esses padrões, e seus valores sobrescrevem headers automáticos com o mesmo nome.

O bloco envia bodies de request JSON pela UI. A tool HTTP por baixo também suporta form data: se você passar parâmetros form-data, ela monta uma request multipart/form-data automaticamente. Na maioria dos casos o campo de body JSON é suficiente.

Common Questions

On this page