The API Call node lets your automation send an HTTP request to any external API when a lead reaches that step. Use it to push lead data to your CRM, trigger a webhook, update an external database, or call any third-party service — all without leaving GetSales.

The node runs instantly (no scheduled delay) and continues to the next step on a successful response, or routes to the error branch if the request fails.

When to use it

Sync leads to an external CRM — POST lead details to HubSpot, Salesforce, or your own backend whenever a lead reaches a certain stage.
Trigger a webhook — notify Zapier, Make, n8n, or a custom webhook when something happens in your automation.
Enrich or update records — call an enrichment API and push the result somewhere else in the flow.
Log events — send a GET or POST to your analytics endpoint each time a lead passes through.

Configuration

When you add an API Call node to your automation, you'll configure the following fields:

Method

The HTTP method for the request. Supported values: GET, POST, PUT, PATCH, DELETE.

Endpoint (URL)

The URL to send the request to. Supports Twig variables (see below), so you can embed lead data directly in the URL — for example:

https://api.example.com/contacts/{{ lead.email }}

Headers

A key-value map of HTTP headers to include in the request. Common use: Authorization, Content-Type, X-API-Key.

Note: headers are sent as-is — Twig variables are not evaluated in header values. If you need a dynamic authorization token, use an API Call Account (see below) or construct the token before the node.

Request body

The body of the request. Which field is used depends on the method:

GET — uses the Query field (sent as query parameters).
POST / PUT / PATCH / DELETE — uses the Body field.

All body and query values support Twig variables, so you can insert lead, company, and sender data into the request.

API Call Account (optional)

Link the node to a stored API Call Account for credential injection. When set, the integrations gateway automatically attaches the account's credentials to the request — useful for APIs that require OAuth tokens or API keys without hardcoding them in headers.

Timeout

How long to wait for a response before treating the request as failed. Default: 15 seconds.

Auto-retry on errors

When enabled, the gateway will automatically retry the request if the target API returns an error status code. Useful for flaky endpoints.

Remove empty values

When enabled, any body keys whose values resolve to empty after Twig evaluation are stripped from the request before sending. Helpful when your body template has optional fields that may not be populated for every lead.

Twig variables

The endpoint URL and request body support Twig templating. You can insert dynamic values from the current lead, company, sender profile, mailbox, and user. Common variables:

Variable	Example
`{{ lead.email }}`	Lead's email address
`{{ lead.first_name }}`	Lead's first name
`{{ lead.last_name }}`	Lead's last name
`{{ lead.linkedin_url }}`	Lead's LinkedIn profile URL
`{{ company.name }}`	Company name
`{{ sender_profile.name }}`	Sender profile display name
`{{ mailbox.email }}`	Sender's mailbox email
`{{ user.name }}`	Team member name

Variables are resolved at execution time using the lead's current data. If a variable doesn't exist for a given lead, it resolves to an empty string (which can be stripped with Remove empty values).

Testing your configuration

Before activating the automation, you can test-call the API directly from the node editor. The test sends a real HTTP request with sample data so you can verify that your endpoint, headers, and body are correct. Check the response status and body in the test result panel.

How it executes

When a lead reaches the API Call node, GetSales merges the node's configuration with the current task data.
Twig variables in the endpoint URL and request body are resolved using the lead's data.
If Remove empty values is on, empty keys are stripped from the body.
The request is forwarded to the integrations gateway, which performs the actual HTTP call to the target API.
On success (HTTP 200): the node completes and the lead moves to the next step in the automation.
On failure (HTTP error or timeout): the node throws an error. The lead routes through the flow node's error handling — depending on your automation setup, this may retry, skip, or route to an error branch.

Limitations

No response mapping. The API Call node does not currently write the target API's response back into the lead record. It sends the request and checks for success/failure, but the response body is not stored or available to subsequent nodes.
Headers are not templated. Twig variables work in the endpoint URL and request body, but not in headers. Use an API Call Account for dynamic credentials.
Runs instantly. There is no built-in delay or scheduling within the node itself. If you need a delay before the API call, add a Wait node before it in the automation.

Error handling

If the target API returns a non-success status code (400, 500) or the request times out, the node fails with an API Call failed error. This error is handled by the automation's normal flow-node error logic:

If Auto-retry on errors is enabled, the gateway retries automatically before reporting failure.
If the node has an error branch configured, the lead routes there.
Otherwise, the lead's task is marked as failed with the error message from the target API.

To debug a failed API Call, check the task's error message — it will include the HTTP status code and any message returned by the target API.

Example: push a lead to an external CRM

A typical setup to sync new leads to a third-party CRM via webhook:

Method: POST
Endpoint: https://hooks.example.com/new-lead
Headers: Content-Type: application/json, Authorization: Bearer your-api-key
Body:

{   
"first_name": "{{ lead.first_name }}",   
"last_name": "{{ lead.last_name }}",   
"email": "{{ lead.email }}",   
"linkedin": "{{ lead.linkedin_url }}",   
"company": "{{ company.name }}",   
"source": "getsales" 
}