Call API

Overview

The Call API stage lets your flow connect to an external service, send or retrieve data, and use the response in the next stages of your flow.

Note: The variable names, values, criteria, and configuration used in this example are for demonstration purposes only.

When to Use

Connect to third-party services (Slack, Salesforce, Stripe, etc.)
Fetch data from external databases or systems
Send notifications or updates to external platforms
Trigger actions in other applications
Retrieve real-time information from web services
Submit data to webhooks or API endpoints
Integrate with custom-built APIs

Configuration

Fields Reference

Field	Type	Required	Description	Example
URI Base	String	Yes	Base path of API endpoint (must include protocol: https:// or http://)	`https://api.slack.com/`
URI Path	String	Yes	Specific endpoint path after base URL (no leading slash)	`api/chat.postMessage`
Method	String	Yes	HTTP method (GET, POST, PUT, PATCH, DELETE)	`POST`
Output Variable	String	Yes	Variable name to store API response (default: body)	`apiResponse`, `userData`
Payload	JSON/ String	No	Request body for POST/ PUT/ PATCH requests	`{"key": "{{value}}"}`
Header Key	String	No	The key of an additional HTTP header. You can add several header key/value pairs.	`Authorization`, `Content-Type`
Header Value	String	No	The value associated with the header key.	`Bearer` `{{token}}`
Route through Fixed IP	Boolean	No	Enable for IP whitelisting requirements (default: false)	Enabled/Disabled
Asynchronous Request	Boolean	No	Make call without waiting for response (default: false)	Enabled/Disabled

API Response

After the HTTP call is made, the response is automatically stored in the configured output variable. If the response is detected as a JSON object, it is also stored as an object so that individual data elements can be accessed in later stages.

For example, if the output variable is called response and the JSON response contains a field called name, access it by referencing response.name.

Route Through Fixed IP

To use this option, you must first enable Advanced Features. Once enabled, you can select Route Through Fixed IP in the Call API stage.

Use this setting when the external API requires requests to originate from a predefined allowlisted set of IP addresses. Enabling it ensures that API calls are routed through Flows’ fixed IP addresses.

The following IP addresses should currently be allowlisted:

174.138.100.69
138.68.114.179
161.35.209.121
139.59.155.107

Exit Points

Exit	When	Response Data
Pass	API call succeeded with 2xx status code (200, 201, 204, etc.)	✓ Stored in output variable
Fail	API returned 4xx client error (400, 401, 403, 404, etc.)	✓ Still stored for error handling
Error	Network error, timeout, or connection failure	✗ No response available
Timeout	Request exceeded 10 seconds (sync) or 2 seconds (async)	✗ No response available

How It Works

When executed, the stage:

Constructs URL - Combines URI Base + URI Path (handles slashes automatically)
Processes Headers - Adds default headers (Content-Type, Accept-Encoding) and custom headers
Executes Request - Sends HTTP request with configured method and payload
Handles Response - Decompresses if needed (Gzip, Brotli supported)
Parses Response - Auto-converts XML to JSON; stores non-JSON in {{variable}}.NonJSON
Routes Exit - Pass (200-208), Fail (other codes), Error (network issues)

Response Format

The response is automatically parsed and stored in your output variable:

JSON Responses (Most Common)

Automatically parsed into nested variables
Access using dot notation: {{variable}}.field.subfield
Arrays accessible by index: {{variable}}.items.0.name
Response code: {{variable}}.responseCode (always available)

XML Responses

Automatically detected when response starts with <
Converted to JSON format automatically
Access using dot notation like JSON

Plain Text / Non-Parseable Responses

Stored in {{variable}}.NonJSON field
Useful for CSV, HTML, or other non-JSON formats

Response Metadata (Always Available)

{{variable}}.responseCode - HTTP status code (200, 404, 500, etc.)
{{variable}}.responseMessage - Status message (on error responses)

Common Use Cases

1. Send Slack Message

URI Base: https://slack.com/
URI Path: api/chat.postMessage
Method: POST
Headers: Authorization: Bearer {{slackToken}}
Payload: {"channel": "C1234567890", "text": "Hello from Flows!"}

2. Fetch User Data

URI Base: https://api.example.com/
URI Path: v1/users/{{userId}}
Method: GET
Headers: X-API-Key: {{apiKey}}

3. Update Record

URI Base: https://crm.example.com/
URI Path: api/customers/{{customerId}}
Method: PATCH
Payload: {"status": "active", "lastContact": "{{currentDate}}"}

Key Behaviors

Feature	Behavior
Timeout	10 seconds (sync), 2 seconds (async)
Compression	✓ Gzip, Brotli supported; ✗ Deflate NOT supported
Redirects	✓ Automatically followed (301, 302, 307)
SSL/TLS	✓ Standard CA certificates; ✗ Self-signed fail
Retry Logic	✗ No automatic retries (implement in flow if needed)
Response Headers	✗ Not included in output (body and metadata only)

Do's and Don'ts

Do	Don't
✓ Handle all exit points (Pass, Fail, Error, Timeout)	✗ Construct URLs incorrectly (double slashes)
✓ Use meaningful output variable names (userData, not body)	✗ Forget authentication headers (causes 401/403)
✓ Store sensitive tokens in variables, never hardcode	✗ Use wrong Content-Type header
✓ Include proper headers (Content-Type for payloads)	✗ Send payload with GET (use query parameters)
✓ Test with small payloads first	✗ Skip Fail exit handling
✓ Handle rate limits with delay stages	✗ Hardcode sensitive data (security risk)
✓ Use fixed IP only when required for whitelisting	✗ Assume all calls succeed
✓ Validate URLs carefully (protocol, slashes)	✗ Ignore response status codes

Troubleshooting

Issue	Common Cause	Fix
Double slash in URL (//users)	URI Base ends with / and URI Path starts with /	Remove leading / from URI Path
401 or 403 authentication errors	Missing or incorrect authentication headers	Add required auth headers (Authorization, X-API-Key, Bearer token)
API rejects request	Wrong Content-Type header	Set Content-Type to match payload format (usually application/json)
GET request fails with body	API rejects GET requests with payload	Use query parameters in URI Path instead of payload
Flow stops after API call	Fail exit not connected	Always connect Fail exit to handle 4xx client errors
Variable not replaced	Incorrect variable syntax	Use {{variableName}} syntax for all variable references
Connection timeout	API endpoint unreachable or slow	Check network connectivity; connect Timeout exit; verify URI Base
Rate limit errors (429)	Too many requests to API	Implement delay stages between calls; handle on Fail exit

Edge Cases

HTTP Status Codes

200-208: Success → Pass exit
3xx Redirects: Automatically followed → Final response goes to Pass
4xx Client Errors: → Fail exit (response still captured)
5xx Server Errors: → Fail exit

Compression Encoding

Gzip: ✓ Fully supported, automatically decompressed
Brotli (br): ✓ Fully supported, automatically decompressed
Deflate: ✗ NOT supported - returns error message

Empty Responses (204 No Content)

Handled gracefully, no error
Response code available: {{variable}}.responseCode = 204
No body data stored

Asynchronous Mode

Executes request in background
Does NOT wait for response or return data
Errors logged but don't fail flow
Use only when response not needed

Building Apps

The Call API stage is the primary tool for creating apps in the Flows platform. Apps are pre-configured flows that users can install and use directly as stages in their own flows by simply providing their API credentials.

What are Apps?

Apps are flows that encapsulate API integrations
Users install apps and set their own credentials (API keys, tokens, etc.)
Once installed, the app becomes a reusable stage in the user's flow builder
Apps abstract away API complexity, making integrations accessible to all users

How Call API Enables Apps

The Call API stage forms the core of app flows
App developers use Call API to define API requests, authentication, and response handling
Users who install the app provide their own API credentials
The platform handles credential storage and injection into Call API stages

Use Cases for Apps

Pre-built integrations for popular services (Slack, Salesforce, Stripe, etc.)
Custom internal API integrations for enterprise clients
Reusable API workflows that multiple teams can use with their own credentials
Turnkey solutions that hide API complexity from end users

For more information, see How to Develop Apps.

Related Stages

Fetch Data: Retrieve stored data from flow storage instead of external APIs
Save Data: Store API responses for later use
Route Flow: Make decisions based on API response values
Change Data: Transform API response data before using it
Loop: Process multiple API calls for array data