# External API integration

Configure HTTP methods, URLs, headers, query parameters, request bodies, and response extractors to connect Chatigram workflows to business software.

## Plan availability

| Feature | Free | Starter | Pro | Enterprise |
| --- | --- | --- | --- | --- |
| Active workflows | 3 | 10 | 45 | Unlimited |

Allowances follow the [published Chatigram pricing page](https://chatigram.com/pricing/). Your organization’s Billing & Plans screen confirms its subscription and current usage. Plans can change. Plan information reviewed 2026-11-10.


## When to use this node

Send any generic HTTP request

Add **External API integration** to a workflow branch using the node picker. Configure its fields in the inspector, then connect the next step.

## Connect software through its API

Use **External API integration** to call an API from a workflow, including software without a dedicated Chatigram action. Examples include checking an order, looking up a CRM contact, creating a service request, or reading stock from an ERP.

You need the destination API's documentation, permission to use it, and a clear idea of what the request will read or change. A generic HTTP node does not automatically connect an account or discover the provider's schema.

## Configure the Request section

| Setting | How to use it |
| --- | --- |
| **Method** | Choose the method required by the destination API |
| **URL** | Enter the absolute address including `https://`; keep query parameters in their own section |
| **Headers** | Add the names and values required by the provider, such as `Accept` or `Content-Type` |
| **Query Parameters** | Add each key and value separately; values are encoded when the request is built |
| **Request Body** | Supply the body the API expects, using variables where needed |

The URL, header values, query values, and body support expressions. Select a prior output or a [Property](/workflows/properties/) through the variable picker rather than pasting a guessed reference.

### Choose a method deliberately

Common patterns are **GET** for reading, **POST** for creating or submitting, **PUT** for replacing, **PATCH** for partial changes, and **DELETE** for removal. The provider's API documentation decides what a particular endpoint actually does. The selector also offers **HEAD**, **OPTIONS**, and **TRACE** where a documented API requires them.

Start with a read request against a test resource. Do not switch a working lookup to a write method without reviewing the destination and body.

## Example: look up an order

Suppose your provider documents a GET lookup with an order number as a query parameter. Configure the node like this:

| Field | Example |
| --- | --- |
| Method | GET |
| URL | `https://api.example.com/orders` |
| Headers | `Accept` = `application/json` |
| Query Parameters | Key `orderNumber`; select the customer's order-number variable for its value |
| Request Body | Leave empty for this example |

The example domain is a placeholder. Replace the URL and field names with your provider's documented contract. Do not put `?orderNumber=...` into **URL** as well as adding it in **Query Parameters**.

If the provider requires authorization, configure it according to its instructions. This node does not turn a header or Property into a protected secret store. Keep live credentials out of shared JSON, public examples, and assistant prompts. Use an appropriate protected connection or [Signed API Request](/nodes/signed-api-request/) when that supported approach fits the service.

## Send a JSON body

For an API that accepts JSON, set the required **Content-Type** header and build the expected object in **Request Body**. For example:

```json
{
  "name": "Example customer",
  "request": "Please arrange a product demonstration"
}
```

Replace the sample values with selected variables where appropriate, retaining valid JSON structure. Check quotes, backslashes, and line breaks in real input. Sending JSON does not guarantee the receiving API accepts those field names or treats the write as duplicate-safe.

Move changeable public information, such as a resource URL or department code, into workflow Properties. Keep per-customer values in variables from the current run.

## Configure the Response section

Every response extractor creates a variable that later steps can select. Give each **Variable Name** a distinct, meaningful name. Use **Get Whole Content** for the full response body as text, or **Extract JSON Value** for a specific value.

Suppose the response body is:

```json
{
  "order": {
    "id": "ORDER-1042",
    "status": "ready",
    "total": 125.5
  },
  "items": [
    { "name": "Example item" }
  ]
}
```

Create these **Extract JSON Value** entries:

| Variable Name | JSON Path | Extracted text |
| --- | --- | --- |
| orderId | `order.id` | `ORDER-1042` |
| orderStatus | `order.status` | `ready` |
| orderTotal | `order.total` | `125.5` |
| firstItemName | `items.0.name` | `Example item` |

Paths use dot notation, including zero-based array positions. Use `items.0.name`, not bracket notation or a guessed JSONPath expression. Extracted JSON values are exposed as text, including numbers. Use **As Number** in [Check condition](/nodes/if-statement/) when comparing an amount numerically.

A missing or JSON `null` field does not provide a usable extracted value. Check for missing data before using it in a message or another request. An empty whole body becomes an empty string. If the API returns non-JSON content, a JSON extractor can fail even when the request itself succeeded.

## Continue the example with Properties and a condition

To route a ready order at or above a configurable amount:

1. Create a workflow Property labeled **Minimum order amount**, with Value `100`.
2. Configure the lookup and extract **orderTotal** and **orderStatus** as shown above.
3. On the API node’s **Success** branch, first check that the extracted values are present. Route missing values to a useful fallback before numeric comparison.
4. Add a second **Check condition** with an **AND** group: **orderTotal → As Number → is greater than or equal to → Variable: Minimum order amount**, and **orderStatus → As Text → equals → Value: ready**.
5. Connect **Yes** to the intended ready-order path and **No** to the alternative. Connect the API node’s **Error** branch separately.

These are picker selections and editor settings, not text to paste as an expression. This example expects the API to supply a valid numeric total; validate or normalize other input before using **As Number**.

| Returned total | Returned status | Expected outcome |
| --- | --- | --- |
| `125.5` | `ready` | Yes: both rules match the sample Property value |
| `80` | `ready` | No: the amount is below the threshold |
| `125.5` | `pending` | No: the status does not match |
| Missing | `ready` | Missing-value fallback before numeric comparison |

Changing the Property changes the threshold without repeating it in each rule. See [Properties](/workflows/properties/) for creating and selecting it.

## Understand Success and Error

**Success** means the request and configured extraction completed successfully. It does not necessarily mean the business operation was accepted: some APIs return a normal response containing a business-level rejection or a not-found result. Inspect the provider's response fields with **Check condition** before telling a customer the task is complete.

**Error** handles HTTP error responses, connection or timeout failures, and supported response-processing failures. The `error` variable provides an explanation. Route that branch to useful handling rather than displaying raw errors to a customer. Response extractor variables should not be assumed to exist on an error path.

This node's built-in `error` variable and configured response extractors are different outputs. The default whole-body extractor is named `response`; add explicit extractors for individual values instead of assuming a status-code or response-header variable exists.

## Test and extend the request

Test a valid response, an empty result, a missing expected field, an HTTP rejection, and a connection failure with controlled resources. After changing an extractor name, update any later references.

Before retrying a write, check whether the destination already accepted it. Use the provider's supported duplicate-prevention mechanism when available. A timeout alone does not prove that no change happened.

For complete patterns, see [CRM contact lookup](/recipes/crm-contact-lookup/), [CRM lead intake](/recipes/crm-lead-intake/), and [ERP stock lookup](/recipes/erp-stock-lookup/). To receive requests instead, use a [Webhook or HTTP Endpoint workflow](/integrations/http-api/).


## Configure the fields

| Field | What to enter |
| --- | --- |
| **Method** | The HTTP request method to use for this request |
| **URL** | Absolute URL including protocol (e.g., https://api.example.com/users). Do not include query strings here. |
| **Headers** | HTTP headers to include with the request. Common headers include Content-Type, Authorization, etc. |
| **Query Parameters** | Query strings to append to the URL. These will be automatically encoded and added to the path. |
| **Request Body** | The body content to send with the request. Commonly used with POST, PUT, and PATCH methods. |

## Use the result

Choose the output from the variable picker in a later step. Output names below identify the values supplied by this node; the picker inserts the correct reference for your node instance.

| Output | Meaning / label |
| --- | --- |
| `error` | error |
| `response` | response |

## Connect the next step

This definition exposes these paths:

- **Success** — branch 1.
- **Error** — branch 2.

Connect each relevant outcome, especially any error or timeout path. Outputs can differ by outcome; check that a result exists before using it.

## Test it in a workflow

1. Configure this node with a small, recognizable test input or a test resource.
2. Check the variables from preceding steps and the connection selected in the inspector.
3. Save the workflow. For event-driven flows, generate the actual event; use **Run** only for a Manual workflow.
4. Open **Workflow Activity** and check the outcome before enabling wider use.

## If something goes wrong

- Check empty variables, selected resource IDs, and any fields that appeared after resource selection.
- Check the failed step in Workflow Activity before retrying. If the action may already have completed, inspect the destination first to avoid duplicates.
- Follow the [troubleshooting guide](/help/troubleshooting/) for a symptom-by-symptom checklist.

## Related guides

- [Work with variables](/workflows/variables/)
- [Understand branches and error handling](/workflows/branches/)
- [Browse all nodes](/reference/nodes/)
- [A/B Testing](/nodes/ab-testing/)
- [Analyze Image](/nodes/attachment-analyze-image/)
- [Ask Multiple Choice Question](/nodes/ask-multiple-choice-question/)
- [ChatGPT Task](/nodes/chatgpt-task/)
- [Check condition](/nodes/if-statement/)


## Catalog coverage

This is the currently documented selection. Chatigram continues to add nodes, triggers, App Connections, and integrations. Use each page’s review date and the current application selectors to check what is available now; this catalog is not a fixed limit on future features.