The Response block

The Response block is a special block that can only be added to actions. The Response block sends data back to a request made to a deployed action’s URL. It receives data from other blocks in the action that are connected to its input ports. Every new action automatically includes one Response block. You can add multiple Response blocks, but there can only be one Response block for each branch of the action's logic. You must design the logic such that whatever happens in the action, only one Response block will be triggered.

Inputs

Status Code - When an HTTP request is sent to deployed action's URL, the action determines what HTTP status code to send in the response. By default, every action has a Response block that sends a 200 ("success") status code. This Response block, situated at the end of the action's sequence of blocks, confirms that the action completed its work.
Headers (optional) - Add a key-value pair for every HTTP header that you want the action's HTTP response to send. You can connect the Headers input to another block, if desired.
Body - Specify an HTTP response body that you want the action's HTTP response to send. Although strictly speaking, this is required, the response body can be an empty string.

The Response block can accommodate the requirements of a variety of use cases besides those covered by these defaults. For details, see the Setup section.

Setup

Status Code - As described in the Inputs section, the Response block sends a 200 status code by default. If you need a Response block to send a different status code, edit the number field.

More advanced options for HTTP status codes and Response blocks include the following:

An action can send success status codes from more than one Response block. For example, in addition to the Response block at the end of the sequence, you can connect another Response block to the Request block, near the beginning. This sends a success response at the moment an HTTP request reaches the action's URL - a useful data point for some testing and automation workflows.
While you can add Response blocks to send 4xx ("failure") status codes, not every action needs to do this. By default, when an action fails, it automatically sends a 400 Bad Request code and records the failure in Flows analytics. This suffices for many internal automation use cases.

To include data from the action in the response headers or body, connect one or more blocks to the corresponding input port. This is optional for the Headers input port and required for the Body input port:

Headers - Actions aren't required to send response headers. Use cases where you'll need them include those where you want to the action's client to be aware of the content type being sent.
Body - It's a best practice to always connect the Body input to another block. Consider the following options:
- If you want the action's response body to replicate the incoming request body, connect the Response block's Body input to the Request block's Body output.
- If you want the action to send a message immediately upon receiving a request, connect a Template or Record block with the desired "request received" message to the Body output of the Request block. Then connect the Response block's Body input to the Template or Record block.
- If you want the action to send an empty response body, connect a Template block with no content in its text box to the Body output of the Request block. Then connect the Response block's Body input to the Template block.

Example

Here's an example that shows how content sent to the Response block's Body input port (in this case, a message) appears in the response body. To make it clear that the message ("Testing my action URL") is present, the Response block's output is selected in the example. There's also a Display block to show that the Template block's output is what's being sent to the Response block.