Response

O bloco Response encerra um workflow e retorna uma resposta HTTP estruturada para quem chamou. Use-o junto com um deploy por API para controlar exatamente o corpo, o status code e os headers que voltam.

Um bloco Response é um ponto de saída. Quando ele executa, o workflow termina e a resposta HTTP é enviada imediatamente. Você pode colocar vários em ramificações diferentes (depois de um Router ou Condition); o primeiro a executar define a resposta.

Configuração

Response Data Mode

O modo Builder monta o corpo da resposta campo por campo, com tipos; o Editor é um editor de código JSON puro. O Builder atende à maioria dos casos.

Response Data

O corpo devolvido, em JSON. Referencie qualquer valor anterior: a saída de um block, como <agent.content>, com uma connection tag, ou uma variável do workflow, como <variable.userId>. Aninhe objetos e arrays livremente.

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

Status Code

Qualquer status code HTTP válido; o padrão é 200. Use 4xx ou 5xx em ramificações de erro (201 criado, 400 requisição inválida, 404 não encontrado, 500 erro de servidor).

Response Headers

Headers extras na resposta, como pares chave-valor:

ChaveValor
Content-Typeapplication/json
Cache-Controlno-cache
X-API-Version1.0

Saídas

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

Não coloque um bloco Response em paralelo com blocks que tenham efeitos colaterais importantes. A ordem entre ramificações paralelas 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> para o corpo e retorna 200 a quem chamou a API.

Confirmar um webhook

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

Retornar um status diferente por ramificação

Um Condition envia as requisições válidas para um Response 200 e as inválidas para um 400. O primeiro Response a executar define o que o chamador recebe.

Boas práticas

  • Use status codes precisos. 2xx para sucesso, 4xx/5xx para erros, definidos por ramificação.
  • Mantenha um formato de resposta consistente entre seus endpoints, para que os chamadores possam confiar nele.
  • Retorne uma resposta diferente por resultado. Coloque um Response em cada ramificação depois de um Condition ou Router.
  • Confira se suas referências resolvem. Uma connection tag que aponta para um block que não executou volta vazia, então defina os campos na ramificação que os produz.

Common Questions

Sim. Coloque-os em ramificações diferentes (depois de um Router ou Condition). O primeiro bloco Response a executar define a resposta da API e encerra o workflow — por exemplo, um 200 na ramificação de sucesso e um 500 na de erro.
Ele foi desenhado para o trigger de API. Quando o workflow é invocado pela API, o bloco Response envia a resposta HTTP estruturada de volta ao chamador. Outros triggers, como webhooks ou agendamentos, não exigem um.
O modo Builder é uma interface visual para montar a estrutura da resposta com campos e tipos. O modo Editor é um editor JSON puro, no qual você escreve o corpo da resposta diretamente. O modo Builder atende à maioria dos casos.
Se você não definir nenhum, o bloco Response retorna 200 (OK). Você pode usar qualquer status code HTTP válido, incluindo códigos de erro como 400, 404 ou 500.
Não. Blocks Response são pontos de saída — eles encerram a execução e enviam a resposta HTTP, então nenhum block executa depois de um.
ParallelWebhook