Response

O bloco Response encerra um workflow e retorna uma resposta HTTP estruturada ao caller. Use com um deployment de API para controlar o body, o status code e os headers exatos que voltam.

Um bloco Response é um ponto de saída. Quando um roda, o workflow termina e a resposta HTTP é enviada imediatamente. Você pode colocar vários em branches diferentes (depois de um Router ou Condition); o primeiro a rodar determina a resposta.

Configuração

Response Data Mode

Builder monta o body da resposta campo a campo com tipos; Editor é um editor de código JSON cru. Builder serve na maioria dos casos.

Response Data

O body enviado de volta, como JSON. Referencie qualquer valor anterior: uma saída de bloco como <agent.content> com uma connection tag, ou uma variável de workflow como <variable.userId>. Aninhe objetos e arrays livremente.

{
  "query": "<start.input>",
  "answer": "<agent.content>",
  "model": "<agent.model>"
}

Status Code

Qualquer código de status HTTP válido; o padrão é 200. Defina 4xx ou 5xx em branches de erro (201 created, 400 bad request, 404 not found, 500 server error).

Response Headers

Headers extras de resposta, como pares chave-valor:

Key	Value
Content-Type	application/json
Cache-Control	no-cache
X-API-Version	1.0

Saídas

Um bloco Response é um bloco terminal, então nada lê dele. Seus data, status e headers viram a própria resposta HTTP. Um workflow sem bloco Response retorna a saída do último bloco por padrão; adicione um bloco Response quando precisar de controle HTTP exato.

Não coloque um bloco Response em parallel com blocos que têm side effects importantes. A ordem entre branches parallel não é determinística, então o Response pode disparar antes ou depois deles em qualquer execução.

Exemplos

Retornar dados de um endpoint de API

O bloco Response lê <agent.content> no body e retorna 200 ao caller da API.

Confirmar um webhook

Depois de processar o payload, o bloco Response retorna uma confirmação pequena para o sender saber que o evento foi recebido.

Retornar um status diferente por branch

Um Condition roteia requests válidas para um Response 200 e inválidas para um 400. O primeiro Response a rodar determina o que o caller recebe.

Boas práticas

Use status codes precisos. 2xx para sucesso, 4xx/5xx para erros, definidos por branch.
Mantenha uma forma de resposta consistente entre seus endpoints para os callers poderem confiar nela.
Retorne uma resposta diferente por resultado. Coloque um Response em cada branch depois de um Condition ou Router.
Cheque se suas referências resolvem. Uma connection tag apontando para um bloco que não rodou volta vazia, então defina campos no branch que os produz.

Common Questions

Sim. Coloque-os em branches diferentes (depois de um Router ou Condition). O primeiro bloco Response a rodar determina a resposta da API e encerra o workflow — por exemplo um 200 no branch de sucesso e um 500 no branch de erro.

Ele é feito para o trigger de API. Quando o workflow é invocado pela API, o bloco Response envia a resposta HTTP estruturada de volta ao caller. Outros triggers como webhooks ou schedules não exigem um.

O modo Builder é uma interface visual para construir a estrutura da resposta com campos e tipos. O modo Editor é um editor JSON cru onde você escreve o body da resposta diretamente. O modo Builder serve na maioria dos casos.

Se você não definir um, o bloco Response retorna 200 (OK). Você pode definir qualquer código de status HTTP válido, incluindo códigos de erro como 400, 404 ou 500.

Não. Blocos Response são pontos de saída — eles encerram a execução e enviam a resposta HTTP, então nenhum bloco roda depois de um.

Response

Common Questions

On this page