Response
The Response block is the final step in your workflow that formats and sends a structured response back to API calls. It's like the "return" statement for your entire workflow—it packages up results and sends them back.
Response blocks are terminal blocks - they end the workflow execution and cannot connect to other blocks.
Overview
The Response block enables you to:
Format API Responses: Structure workflow results into proper HTTP responses
Set Status Codes: Configure appropriate HTTP status codes based on workflow outcomes
Control Headers: Add custom headers for API responses and webhooks
Transform Data: Convert workflow variables into client-friendly response formats
How It Works
The Response block finalizes workflow execution:
- Collect Data - Gathers variables and outputs from previous blocks
- Format Response - Structures data according to your configuration
- Set HTTP Details - Applies status codes and headers
- Send Response - Returns the formatted response to the API caller
When You Need Response Blocks
- API Endpoints: When your workflow is called via API, Response blocks format the return data
- Webhooks: Return confirmation or data back to the calling system
- Testing: See formatted results when testing your workflow
Two Ways to Build Responses
Builder Mode (Recommended)
Visual interface for building response structure:
- Drag and drop fields
- Reference workflow variables easily
- Visual preview of response structure
Editor Mode (Advanced)
Write JSON directly:
- Full control over response format
- Support for complex nested structures
- Use
<variable.name>syntax for dynamic values
Configuration Options
Response Data
The response data is the main content that will be sent back to the API caller. This should be formatted as JSON and can include:
- Static values
- Dynamic references to workflow variables using the
<variable.name>syntax - Nested objects and arrays
- Any valid JSON structure
Status Code
Set the HTTP status code for the response. Common status codes include:
- 200: OK - Standard success response
- 201: Created - Resource successfully created
- 204: No Content - Success with no response body
- 400: Bad Request - Invalid request parameters
- 401: Unauthorized - Authentication required
- 404: Not Found - Resource doesn't exist
- 422: Unprocessable Entity - Validation errors
- 500: Internal Server Error - Server-side error
- 502: Bad Gateway - External service error
- 503: Service Unavailable - Service temporarily down
Default status code is 200 if not specified.
Response Headers
Configure additional HTTP headers to include in the response.
Headers are configured as key-value pairs:
| Key | Value |
|---|---|
| Content-Type | application/json |
| Cache-Control | no-cache |
| X-API-Version | 1.0 |
Example Use Cases
API Endpoint Response
Scenario: Return structured data from a search API
- Workflow processes search query and retrieves results
- Function block formats and paginates results
- Response block returns JSON with data, pagination, and metadata
- Client receives structured response with 200 status
Webhook Confirmation
Scenario: Acknowledge webhook receipt and processing
- Webhook trigger receives external system data
- Workflow processes the incoming data
- Response block returns confirmation with processing status
- External system receives acknowledgment
Error Response Handling
Scenario: Return appropriate error responses
- Condition block detects validation failure or system error
- Router directs to error handling path
- Response block returns 400/500 status with error details
- Client receives structured error information
Inputs and Outputs
Response Data: JSON structure for response body
Status Code: HTTP status code (default: 200)
Headers: Custom HTTP headers as key-value pairs
Mode: Builder or Editor mode for response construction
response.data: The structured response body
response.status: HTTP status code sent
response.headers: Headers included in response
response.success: Boolean indicating successful completion
HTTP Response: Complete response sent to API caller
Workflow Termination: Ends workflow execution
Access: Response blocks are terminal - no subsequent blocks
Variable References
Use the <variable.name> syntax to dynamically insert workflow variables into your response:
{
"user": {
"id": "<variable.userId>",
"name": "<variable.userName>",
"email": "<variable.userEmail>"
},
"query": "<variable.searchQuery>",
"results": "<variable.searchResults>",
"totalFound": "<variable.resultCount>",
"processingTime": "<variable.executionTime>ms"
}Variable names are case-sensitive and must match exactly with the variables available in your workflow.
Best Practices
- Use meaningful status codes: Choose appropriate HTTP status codes that accurately reflect the outcome of the workflow
- Structure your responses consistently: Maintain a consistent JSON structure across all your API endpoints for better developer experience
- Include relevant metadata: Add timestamps and version information to help with debugging and monitoring
- Handle errors gracefully: Use conditional logic in your workflow to set appropriate error responses with descriptive messages
- Validate variable references: Ensure all referenced variables exist and contain the expected data types before the Response block executes