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://api.gohighlevel.com/v1/contacts/

Method. GET for retrieving data, POST for creating, PUT or PATCH for updating, DELETE for removing. 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 for the key. GoHighLevel uses Authorization: Bearer. Airtable uses Authorization: Bearer. Others use X-API-Key or api-key as the header name. Check the API documentation for the exact header name.

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 directly in the URL or the scenario. Store them in Make.com Data Stores or use the Connection system for reusable auth configurations. This way you rotate credentials in one place and every scenario that uses them updates automatically.

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. 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.