How to Connect External APIs in a Workflow

What an API Node Does in a Workflow

An API node (sometimes called an HTTP Request node) sends an HTTP request to an external URL and returns the response. In a workflow, it works like any other action node: it receives data from previous steps, performs its operation, and makes its output available to the next step.

The difference from other nodes is scope. An email node can only send emails. A database node can only interact with your database. An API node can interact with any system on the internet that has an API: payment processors, CRMs, project management tools, shipping services, weather APIs, government databases, AI models, and thousands more. If a service has a documented API, your workflow can talk to it through an API node.

This makes API nodes the universal connector in workflow automation. When there is no pre-built integration for the tool you need, an API node fills the gap. When the pre-built integration does not support the specific operation you need, an API node gives you direct access to the full API.

Configuring an API Node

Every API request has four components you need to configure: the URL (where to send the request), the method (what type of request), the headers (metadata including authentication), and the body (the data to send).

URL and Method

The URL is the endpoint you are calling. Every API documents its endpoints in its reference guide. For example, Stripe's endpoint to create a charge is https://api.stripe.com/v1/charges. Slack's endpoint to post a message is https://slack.com/api/chat.postMessage. The URL tells the API which resource and operation you want.

The HTTP method tells the API what you want to do with that resource:

• GET: Retrieve data. Read a customer record, fetch a list of orders, check an account balance. GET requests do not modify anything.
• POST: Create something new. Create a customer, submit a form, send a message, initiate a process. POST requests include data in the body.
• PUT or PATCH: Update something that already exists. Change a customer's email, update an order status, modify a record. PUT replaces the entire resource, PATCH updates only the fields you specify.
• DELETE: Remove a resource. Delete a contact, cancel a subscription, remove a file.

The API's documentation tells you which method to use for each endpoint. Using the wrong method (sending a POST to a GET endpoint) results in a 405 Method Not Allowed error.

Headers and Authentication

Headers are key-value pairs sent with the request that provide metadata. The two most common headers are:

Content-Type: Tells the API what format your request body uses. Almost always application/json for modern APIs. Some older APIs use application/x-www-form-urlencoded.

Authorization: Tells the API who you are. This is where authentication goes. The three most common patterns are:

• API key in header: Authorization: Bearer sk_live_your_api_key. Stripe, OpenAI, and many other APIs use this pattern. You get the API key from the service's dashboard.
• API key as query parameter: Some APIs want the key in the URL: https://api.service.com/endpoint?api_key=your_key. Less common and less secure than header-based authentication.
• OAuth tokens: Services like Google, Microsoft, and Salesforce use OAuth. You go through an authorization flow once (granting your workflow permission to access your account), receive an access token, and include that token in the Authorization header. OAuth tokens expire and need refreshing, which your workflow platform usually handles automatically.

Store API keys and tokens in your workflow platform's credential manager, not in the workflow configuration itself. Credential managers encrypt the values and let you reference them by name across multiple workflows without exposing the actual key.

Request Body

POST, PUT, and PATCH requests include a body with the data you are sending. The body is usually JSON formatted. For example, to create a customer in a CRM, the body might include the customer's name, email, phone, company, and source fields as a JSON object.

The body can include static values (always set the source to "website") and dynamic values from workflow variables (set the email to the value captured from the form submission in step 1). Most workflow builders provide a variable picker in the body editor so you can insert dynamic values without manually writing JSON.

Parsing API Responses

When the API responds, it sends back a JSON object with the result of your request. A successful customer creation might return the new customer's ID, creation timestamp, and the full customer record. A failed request returns an error code and message.

Your workflow needs to extract useful values from the response and make them available as variables for subsequent steps. If you created a customer and need the new customer ID for the next step (adding the customer to a group), you extract the ID field from the response and store it as a variable.

Most workflow builders parse JSON responses automatically. The response fields appear in the variable picker for subsequent nodes. Some APIs return deeply nested JSON (the customer ID might be at response.data.customer.id rather than response.customer_id), so check the response structure in the execution log to find the correct path.

Handling API Errors

API calls fail. The external server might be down, your API key might be expired, you might be sending invalid data, or you might have exceeded your rate limit. Every API node in your workflow needs error handling.

HTTP Status Codes

The API's response includes a status code that tells you whether the request succeeded:

• 200-299: Success. The request worked as expected.
• 400: Bad request. Your request body has invalid or missing fields. Fix the data and retry.
• 401: Unauthorized. Your API key or token is invalid, expired, or missing. Check credentials.
• 403: Forbidden. Your API key is valid but does not have permission for this operation. Check the key's permissions in the service's dashboard.
• 404: Not found. The resource (customer, order, record) you referenced does not exist. The ID might be wrong, or the resource was deleted.
• 429: Rate limited. You are sending too many requests too fast. Wait and retry after the delay specified in the response headers.
• 500-599: Server error. The external service is having problems. This is not your fault. Retry after a delay.

Error Handling Strategies

Retry with backoff: For transient errors (429, 500-599), wait and retry. Start with a 5-second delay, double it on each retry (5s, 10s, 20s), and give up after 3-5 attempts. This handles temporary outages without overwhelming the external service.

Conditional error paths: Add a condition after the API node that checks the response status. If the status is 200, continue the normal flow. If the status is 400, log the error and skip the record. If the status is 500, retry. Different error types need different handling. See Error Handling in Automated Workflows.

Fallback actions: If the primary API is down, do you have an alternative? If Twilio is unreachable and you need to send an SMS, can you queue the message and retry later? If the CRM API is down, can you log the data locally and sync it when the CRM recovers? Fallback paths keep your workflow operational when one external dependency fails.

Common API Integration Patterns

Data Enrichment

Your workflow captures basic data (name and email from a form), then calls an external API to add more information. Clearbit returns the person's company, title, and social profiles from their email. FullContact returns additional contact details. Your workflow then has a complete record to work with for lead scoring, routing, and personalization.

Cross-System Sync

When a record is created or updated in System A, your workflow calls System B's API to create or update the matching record there. A new contact in your CRM triggers a workflow that calls your email platform's API to add the contact to the right list. This keeps two systems synchronized without manual data entry.

Action Orchestration

Your workflow calls multiple APIs in sequence to coordinate actions across services. A new order triggers: call the payment API to capture funds, call the inventory API to decrement stock, call the shipping API to create a label, call the email API to send confirmation, and call the accounting API to record revenue. One trigger, five API calls, zero manual steps.

Data Aggregation

A scheduled workflow calls multiple APIs to collect data for a report. Query your analytics API for traffic numbers, your payment API for revenue data, your support API for ticket counts, and your CRM API for pipeline value. Combine the results into one report and deliver it by email every Monday morning.

Rate Limits and Pagination

Most APIs limit how many requests you can make in a given time period. Stripe allows 100 requests per second. Shopify allows 2 per second on basic plans. Slack allows 1 per second for most endpoints. Exceeding these limits results in 429 errors.

For workflows that make many API calls (processing a list of 500 records, each requiring an API call), add delays between requests. A 1-second wait between API calls keeps you under most rate limits. Some workflow platforms handle rate limiting automatically, queuing requests and spacing them to stay within limits.

APIs that return lists of records (all customers, all orders, all invoices) typically paginate results. Instead of returning 10,000 records at once, they return 100 at a time with a link to the next page. Your workflow needs to loop: call the API, process the results, check if there is a next page, and if so, call the API again with the pagination token. Most workflow builders have loop nodes that handle this pattern.