Make.com HTTP Module Tutorial: How to Connect Any API Without a Native Connector

The Make.com HTTP module is one of the most useful tools in the platform and one of the most underused by beginners. Most people build exclusively with native connectors — the pre-built modules for Google Sheets, Slack, HubSpot, and so on. That works until you need to connect a service that does not have a native connector, or until you need more control over an API call than the native module allows.

The HTTP module removes both limitations. If a service has an API, you can connect it to Make.com. That covers thousands of tools that have no native Make connector and gives you full control over request headers, body format, authentication, and response handling.

This tutorial covers the HTTP module from basic GET requests through authenticated POST calls, pagination, and error handling. If you're new to Make.com entirely, start with Make.com Tutorial for Beginners first.

When to Use the HTTP Module

Three situations call for the HTTP module over a native connector.

First, the service you need has no native Make.com connector. A niche CRM, a custom internal API, a newer SaaS tool, a client's bespoke platform. If it has an HTTP API, the HTTP module connects to it.

Second, the native connector exists but does not expose the specific endpoint you need. Native connectors cover the most common actions but rarely the full API surface. The HTTP module lets you call any endpoint the API offers.

Third, you need to handle the raw response yourself. Native connectors parse the API response and present it in a fixed structure. The HTTP module gives you the raw response body, which you parse and map exactly as your scenario requires.

The Basic Structure of an HTTP Request

Every HTTP request in Make.com needs four things at minimum: a URL, a method, headers, and a body (for POST, PUT, and PATCH requests).

Open a scenario and add the HTTP module. Select Make a request as the action. You will see fields for:

URL. The full endpoint URL including any path parameters. Example: https://rest.gohighlevel.com/v1/contacts/

Method. GET for retrieving data, POST for creating, PUT or PATCH for updating, DELETE for removing. RFC 9110 defines what each method is meant to do, but match what the API documentation specifies for the endpoint you are calling.

Headers. Key-value pairs sent with the request. Most APIs require at least a Content-Type header (application/json for JSON APIs) and an Authorization header for authentication.

Body. For POST and PUT requests, the data you are sending. Set the body type to Raw and the content type to JSON, then write or map the JSON payload.

Parse response. Toggle this on. It tells Make to parse the response body as JSON automatically, making the response fields available for mapping in downstream modules.

Authentication: The Part That Trips People Up

Most API calls require authentication. The three formats you will encounter most often are Bearer token, API key in header, and Basic auth.

Bearer token. The most common format for modern APIs. Add a header with the key Authorization and the value Bearer YOUR_TOKEN_HERE. In Make, you map the token from a data store or an environment variable rather than hardcoding it.

API key in header. Some APIs use a custom header name rather than Authorization. X-API-Key and api-key are the two you will meet most often, and a few services invent their own entirely. There is no guessing this one — check the documentation for the exact header name and the exact prefix, because a value that is correct but missing its Bearer prefix fails identically to a wrong key.

Basic auth. Older APIs use HTTP Basic authentication. In Make, select Basic Auth as the auth type in the HTTP module and enter your username and password. Make handles the Base64 encoding automatically.

Never hardcode credentials in the URL or paste them into the module by hand. Use a Connection where the service has one, and Make's keychain for raw API keys, so the value is stored as a secret and rotated in one place. Data stores are not the right home for this — they are ordinary readable storage, and anything you put there is visible to anyone with access to the team.

One note on GoHighLevel specifically, since it is the example used below: the v1 REST API and its Location API keys are the older generation, and GHL has been steering integrations towards the v2 API with OAuth for some time. The mechanics of the HTTP module are identical either way, but check which version your account and endpoint are actually on before you build, because tutorials written against v1 will point you at a base URL that may no longer be the one you want.

A Real Example: Creating a GoHighLevel Contact via HTTP

GoHighLevel has a native Make connector, but the HTTP module approach illustrates the pattern that applies to any API — the same pattern behind the Retell-to-GHL integrations covered in Make.com Webhook Tutorial.

The GHL API endpoint for creating a contact is: POST https://rest.gohighlevel.com/v1/contacts/

The required header is: Authorization: Bearer YOUR_GHL_API_KEY

The request body (JSON) looks like:

{
  "firstName": "Sarah",
  "lastName": "Johnson",
  "email": "sarah@example.com",
  "phone": "+14085551234",
  "tags": ["web-lead", "organic"]
}

In Make, you map each field from upstream modules rather than hardcoding values. The firstName comes from {{1.caller_name_first}}, the email from {{2.email}}, and so on. Every time the scenario runs, the HTTP module sends the correct data for that specific execution.

The response from GHL returns the created contact object including the new contact ID. With Parse Response toggled on, that ID is available in downstream modules — useful if you need to take further actions on the contact immediately after creation.

Handling Pagination in API Responses

Many APIs return paginated results. A request for all contacts in a CRM might return 100 results with a cursor or page token pointing to the next 100. Getting all results requires making multiple requests until there are no more pages.

Make.com handles this with the Pagination section of the HTTP module. Toggle Enable pagination on and configure it based on how the API paginates.

For cursor-based pagination: set the pagination type to Response-based, specify the field path that contains the next page cursor in the response, and set that cursor value as a parameter in the next request URL. Make loops through pages automatically until the cursor field is empty or null.

For offset-based pagination: set the pagination type to Offset and configure the offset increment and the maximum number of requests. Make increments the offset parameter on each request until no results are returned.

For Link header pagination (common in GitHub and some REST APIs): Make can read the next page URL from the response Link header and follow it automatically.

Pagination is one of the harder concepts in the HTTP module, but once it is configured for one API it follows the same pattern for others. Use the API Request Tester to inspect the raw response from an API endpoint and identify exactly where the pagination cursor or next-page indicator lives before configuring it in Make.

Parsing Complex Response Bodies

Some API responses return nested JSON with arrays inside objects inside arrays. Make parses the top-level JSON automatically when Parse Response is enabled, but deeply nested structures require some extra handling.

For arrays nested inside the response, add an Iterator module after the HTTP module. Set the Array field to the path of the nested array: {{1.data.results}} for a response where results is inside a data object. The Iterator outputs one item at a time and downstream modules process each one.

For responses where you need to extract a specific value from deep nesting, use the Get function in a Set Variables module: {{get(1.body; "data.contacts.0.email")}} extracts the email from the first contact in a nested contacts array.

When you are working out the path to a nested field, paste the raw response JSON into the JSON Formatter to visualise the structure clearly before writing the path in Make.

Error Handling for HTTP Requests

APIs return errors. Authentication expires, rate limits get hit, required fields are missing, the target resource does not exist. Without error handling, a failed HTTP request stops your entire scenario. Make.com Error Handling covers the broader patterns; here is how they apply specifically to HTTP modules.

Ignore handler. Use this for non-critical requests where a failure should not stop the scenario. The module fails silently, the scenario continues.

Break handler. Use this for critical requests. The scenario stops and Make queues the execution for a retry after a configurable delay. Useful for temporary API outages or rate limit hits.

Rollback handler. Use for scenarios where a failure partway through means earlier steps should be undone. Less common, but useful for financial or inventory operations where partial completion causes problems.

For rate limit errors specifically, add a Sleep module before the HTTP module that retries. Most APIs that rate limit return a 429 status with a Retry-After header telling you how long to wait, and MDN's HTTP status code reference is the quickest way to check what an unfamiliar code means. A Router that checks the response status and routes 429s through a wait-and-retry branch handles this cleanly.

Sending Webhooks Out From Make

The HTTP module is not only for consuming APIs. It is also how you send data from Make to external systems that accept incoming webhooks.

To trigger an n8n workflow from Make: add an HTTP module, set the method to POST, enter the n8n webhook URL, set Content-Type to application/json, and send the relevant data in the body. n8n receives it and processes it exactly as if it came from any other webhook source. n8n Webhook Tutorial covers the receiving side of that exchange.

The same pattern works for triggering Retell AI outbound calls, posting data to a custom FastAPI backend, or notifying any system that accepts HTTP POST.

Combining incoming webhooks (as triggers) with outgoing HTTP calls (as actions) in the same Make scenario lets you build fully bidirectional integrations between any two HTTP-capable systems, regardless of whether Make has a native connector for either.

This kind of HTTP-module integration work — connecting a client's bespoke CRM or a niche industry tool that has no native connector — is a large share of the custom automation builds I take on. If you want help building a specific HTTP integration in Make or are running into issues with authentication or response parsing, book a free 30-minute call. Bring the API documentation for the service you are connecting and we will get it working.

Frequently Asked Questions

Why does my request work in the API tester but fail in Make?

Nine times in ten it is the body, not the authentication. The HTTP module needs the body type set to Raw and the content type set to JSON before it will send what you typed as actual JSON, and leaving it on the form-data default sends something the API will reject with a message that rarely explains why. The other recurring culprits are invisible: a token pasted from a document that arrived carrying a trailing newline or a typographic quote, and a mapped value that resolves to empty because the upstream field was missing on that particular run. Compare the request as Make actually sent it, in the execution history, against the one that worked, rather than comparing what you think you configured.

Where should the API key actually live?

In a Connection if the service has one, otherwise in Make's keychain, and nowhere else. The two places people put keys that they later regret are the module itself, where the key gets copied along with the scenario every time it is cloned or exported, and a data store, which is plain readable storage rather than a secret vault. The practical test is whether you could rotate the key in one place and have every scenario pick it up, and whether someone joining the team gets the ability to use it without the ability to read it.

Why did one scenario run burn thousands of operations?

Pagination, almost certainly. Every page is a separate request and every request is a separate operation, so an endpoint that returns 100 records a page against a CRM holding forty thousand contacts is four hundred operations before any downstream module has done anything at all. Always set a maximum number of pages, always filter server-side with whatever query parameters the API offers rather than pulling everything and filtering in Make, and be wary of a scheduled scenario that re-pulls the full history every fifteen minutes when what you needed was records changed since the last run.

The API returned 200 but nothing was created.

Read the response body rather than the status code. A fair number of APIs, particularly older ones, answer 200 for everything and put the real outcome in the payload, so a validation failure or a rejected field comes back looking like success as far as Make is concerned and the scenario carries on happily. Add a filter or a router after the HTTP module that checks whatever the API uses to signal failure in the body, and route those to an alert. Silent success is worse than a visible error because nothing draws your attention to it.

Does Make store my API key in the execution history?

Yes. Request headers are recorded with the execution, which means the Authorization header and the token in it sit in the history for as long as your retention settings keep it, readable by anyone with access to that team or organisation. This matters most when a client gives you a key for their account and your colleagues, or your own future contractors, can then read it out of an old run. Rotate any key that has been through a shared environment when the engagement ends, and treat execution history as something that contains secrets rather than just diagnostics.

If you would rather have this built than build it, I take on API and Make.com integration work through Upwork.