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. 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 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 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:
{
"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:
{
"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 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:
- Create a workflow Property labeled Minimum order amount, with Value
100. - Configure the lookup and extract orderTotal and orderStatus as shown above.
- 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.
- 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.
- 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 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, CRM lead intake, and ERP stock lookup. To receive requests instead, use a Webhook or HTTP Endpoint workflow.
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 #
- Configure this node with a small, recognizable test input or a test resource.
- Check the variables from preceding steps and the connection selected in the inspector.
- Save the workflow. For event-driven flows, generate the actual event; use Run only for a Manual workflow.
- 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 for a symptom-by-symptom checklist.
Related guides #
- Work with variables
- Understand branches and error handling
- Browse all nodes
- A/B Testing
- Analyze Image
- Ask Multiple Choice Question
- ChatGPT Task
- Check condition
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.