The Response block

The Response block is a special block that’s required to create a deployable flow. The Response block sends data back to a request made to a flow’s URL. It receives data from other blocks in the flow that are connected to its input ports. You can add multiple Response blocks to a flow, but there can only be one Response block for each branch of the flow’s logic. You must design the logic such that whatever happens in the flow, only one Response block will be triggered. To trigger a Response block from a specific output port, such as a Fail port, use its Send input.

Inputs

• Send (optional) - If you connect another block to this input port, that block triggers the Response block to send its response. Use this input to trigger a Response block from a conditional output port, such as the Fail output port of an HTTP Request block. The Send input only triggers the Response block. It doesn’t pass data to the response body. To include data in the response body, connect the Body input. To supply custom response headers, connect the optional Headers input.
• Status Code - When an HTTP request is sent to a flow’s URL, the flow determines what HTTP status code to send in the response. Every flow with a Request block requires at least one Response block that sends a 200 (“success”) status code. This Response block, situated at the end of the flow’s sequence of blocks, confirms that the flow completed its work.
• Headers (optional) - Add a key-value pair for every HTTP header that you want the flow’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 flow’s HTTP response to send. 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:

• A flow 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 flow’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 flow needs to do this. By default, when a flow running in the cloud fails, it automatically sends a 400 Bad Request code and records the failure in Flows analytics. This suffices for many internal automation use cases.

• Send - Connect a block’s output to the Send input to trigger the Response block when that block sends data. For example, to send a custom response when a request fails, connect an HTTP Request block’s Fail output port to the Response block’s Send input, then set the Status Code to the failure code you want to return. You don’t need to add a Template or Evaluate block just to trigger the response.

  When you connect a block to Send and nothing to Body, the response body is null. The data from the block connected to Send isn’t included in the response. To return data in the response body, connect a block to the Body input instead of, or in addition to, the Send input.

To include data from the flow in the response headers or body, connect one or more blocks to the corresponding input port. This is optional for the Headers input port. It’s required for the Body input port if you want the response to include a body:

• Headers - Deployed flows aren’t required to send response headers. Use cases where you’ll need them include those where you want to the deployed flow’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 flow’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 flow 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 flow 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 deployed flow 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.

Related blocks

Deployable flows require one Request or Schedule block. Deployable flows that have a Request block require at least one Response block.