How to Connect to Any REST API Using HTTP Requests

Use the HTTP Requests connector to integrate with any REST API that doesn't have a dedicated connector.

What This Integration Does

Not every system you need to talk to has a first-class Spojit connector. Internal microservices, niche SaaS tools, a partner's bespoke API, a legacy admin endpoint - all of these still speak HTTP, and the http connector lets your workflows make GET, POST, PUT, PATCH, and DELETE calls with full control over URL, headers, query parameters, and body. You get the same retries, logging, and variable bindings as a built-in connector, just without preset auth handling.

Each request runs as a single step. The response status code, headers, and parsed JSON body are available to downstream nodes as {{ stepN.status }}, {{ stepN.headers }}, and {{ stepN.body }}. If the API speaks XML or CSV, pair the call with the xml or csv connector on the next step to parse the body.

Prerequisites

The API base URL and any required headers (auth, content type, custom tenant headers).
An API key, bearer token, or basic-auth credentials - stored in a Connection or passed in via variables.
An idea of which endpoint and method you're calling. For OAuth APIs, a working token-refresh story (often a small subworkflow that runs http-post to the token endpoint).

Step 1: Trigger the Workflow

Start with any Trigger type that fits your use case. Schedule for polling, Webhook for reactive flows, Manual for ad-hoc invocations. The HTTP request itself doesn't care how it was triggered - it just needs whatever variables you reference in URL or body to be in scope.

Step 2: Add an HTTP Connector Node

Drop a Connector node onto the canvas, point it at the http connector, and pick the tool that matches the verb you need: http-get, http-post, http-put, http-patch, http-delete, http-head, or http-request for arbitrary methods. The dedicated verb tools are slightly easier to configure; http-request is the catch-all when you need full control.

Step 3: Configure URL, Headers, and Body

Fill in the request fields. Use handlebars to interpolate variables anywhere - path, query string, header values, body fields. Example for a paged GET:

Tool: http-get
URL: https://api.example.com/v1/customers?status=active&page={{ page }}
Headers:
  Authorization: Bearer {{ connection.token }}
  Accept: application/json

Example for a JSON POST:

Tool: http-post
URL: https://hooks.example.com/incoming
Headers:
  Content-Type: application/json
Body:
{
  "event": "order_created",
  "data": {{ step1 }}
}

Step 4: Check the Response Status

Add a Condition node after the HTTP call. The check should be {{ step2.status }} >= 200 && {{ step2.status }} < 300. Route success to the rest of the workflow and failure to an error branch that logs the response body and notifies the team via a slack send-message call. This is the single highest-value thing you can add when integrating an unfamiliar API.

Step 5: Parse and Use the Response

For JSON APIs the body is already parsed - reference fields directly as {{ step2.body.data.items }}. For other formats, chain a parsing step: xml to-json for XML responses, csv parse for CSV downloads, or the regex extract tool for pulling values out of plain text. A Transform node is the cleanest place to reshape the response into the structure downstream steps expect.

Step 6: Handle Pagination and Rate Limits

If the API returns paged data, wrap the HTTP call in a Loop node (While) that continues while a next cursor exists or the returned page has the full page size. Read the cursor or page number out of the response and bind it back into the next iteration. For rate-limited APIs, watch the response headers - many APIs return X-RateLimit-Remaining and Retry-After; honour them with a small delay before the next iteration.

Tips

Build complex bodies in a Transform node first, then reference the result in the body field - the editor is easier to work with than a giant inline JSON blob.
For OAuth APIs that need a fresh token, factor token refresh into a Subworkflow that returns the current access token. Call it before any HTTP step that needs auth.
The http-head tool is great for cheaply checking whether a resource exists before fetching it.
Log the response body during early testing, then prune the log once the integration is stable - response bodies can contain sensitive data.

Common Pitfalls

Forgetting Content-Type - many APIs reject POST bodies silently or with confusing errors when Content-Type: application/json is missing.
Encoded query parameters - if your variable contains spaces or special characters, use the encoding connector's url-encode tool before interpolating, or put it in the body instead.
Treating 2xx as success - some APIs return 200 with an error object in the body. Check the body shape, not just the status code.
Hardcoding tokens in headers - rotate them through a Connection or environment variable so you can roll them without editing every workflow.

Testing

Trigger the workflow manually with a sandbox or test endpoint first. Inspect the recorded request and response in the execution log to confirm headers, body, and status are what you expect. Once a single call works, exercise the error branch by deliberately breaking auth (wrong token) so you can confirm your Condition routes and notifications fire as designed.