Loading tutorials…
Loading tutorials…
Make has 1,500+ native app integrations. For the 10,000+ APIs that are not native, the HTTP module is your universal connector. Learn it once; integrate anything.
Who this is forOwners and operators who need to integrate with services Make does not have native modules for — internal APIs, niche tools, legacy systems. Required skill once you outgrow the native module library.
What you'll need
Step 1
Before opening Make, read the API documentation. Identify: base URL, auth method, endpoints, request/response format.
Open the target API's developer documentation in a separate tab.
Find the "Authentication" section. Identify: API key (in header? query param?), OAuth, Bearer token, Basic auth, custom auth.
Find the endpoint you need: GET, POST, PUT, DELETE? What is the URL pattern?
Find the request format: query parameters (URL), JSON body, form-encoded body, multipart?
Find the response format: JSON shape, success/error codes, pagination structure.
If you cannot find docs OR the API has no public docs, that is a red flag — usually means flaky or undocumented endpoints.
Step 2
Right-click upstream → Add Module → HTTP → "Make a Request" (most common) or specific HTTP method modules.
On the canvas, right-click the upstream module → "Add another module."
Search "HTTP." Multiple options appear: "Make a Request," "Get a File," "Make a Basic Auth Request," etc.
Pick "Make a Request" for most cases — it is the universal HTTP module.
In the module config: URL (the full endpoint URL), Method (GET/POST/etc), Headers, Query String, Body.
Fill these based on your API docs. Mistake-proof method: copy the curl example from API docs, then translate each piece into the HTTP module fields.
Step 3
Headers for API key + Bearer. Auth setup for OAuth. Body for form-encoded credentials. Pick based on API requirement.
API Key in header (most common): add a Header. Name = "Authorization" or "X-API-Key" (check docs), Value = your key.
Bearer token: add Header. Name = "Authorization," Value = "Bearer YOUR_TOKEN."
Basic auth: in module config, set "Use Authentication" toggle → username + password. Make handles the encoding.
OAuth: use a Connection rather than HTTP module if Make has the OAuth flow. If not, use HTTP "Make an OAuth 2.0 Request" — more complex but handles refresh.
Test the auth alone with a known-good GET endpoint before building the real request. Confirms creds are right.
Step 4
For most modern APIs, the body is JSON. Set Body Type = "Raw," Content Type = "application/json," and write the JSON string.
In the HTTP module config, set Method = POST.
Set "Body Type" to "Raw."
Set "Content Type" to "application/json."
In the "Request Content" field, write the JSON body. Use double-quoted JSON: {"email": "{{1.email}}", "name": "{{1.name}}"}
Make tokens ({{1.email}}) will be substituted at runtime.
Test with Run Once. The output bundle should show the API response. If you get 400 or 422, the JSON body is malformed.
Step 5
HTTP module returns the response as a string + parsed object. Use the parsed object in downstream modules.
After the HTTP module runs, expand the output bundle. You see "Data" (raw string) and parsed fields.
If the API returned JSON, Make auto-parses it. Access fields with {{2.data.user_id}} or similar.
If Make does not auto-parse (rare), add a "Parse JSON" module after the HTTP request. Source = HTTP module data. Map a JSON structure.
For paginated APIs (return only N records per call), use a Repeater module or build a recursive scenario to fetch all pages.
Handle nested arrays with Iterator (covered in the iterators tutorial).
Step 6
Add an error handler. Check for non-2xx status codes. Implement retry-after for 429s.
Right-click the HTTP module → Add error handler → Resume → Slack notification.
In the Slack notification, include the HTTP status code: {{2.statusCode}} and the response body: {{2.data}}.
429 (Too Many Requests): API is rate-limiting. Check response header "Retry-After" — sleep that many seconds then retry.
500-599 (server errors): retry with exponential backoff (30s, 60s, 120s).
400-499 (client errors): usually a bug in your request — DO NOT retry, just notify.
Use module Settings → "Allow autoretry" → set max 3 retries with 30-60s intervals for 5xx errors.
Step 7
For complex APIs, test your full request with curl from terminal. Once it works, port the exact same headers + body to Make.
Open Terminal (Mac) or PowerShell (Windows).
Build your request as a curl command using the API docs example: curl -X POST -H "Authorization: Bearer xxx" -d '{"email":"test@example.com"}' https://api.example.com/contacts
Run it. If it returns 200 + the expected data, the request shape is correct.
Port the headers + body to the Make HTTP module exactly. If Make returns errors but curl works, the issue is in how you copied something.
This curl-first approach saves hours of Make-specific debugging.
Common mistakes
Hardcoding API keys in URLs
What goes wrong: API key visible in scenario blueprints and exports. If you ever share a scenario template, share a screenshot, or export config, the key leaks. Bad actors find these regularly.
How to avoid: Store API keys in scenario-level Variables or in a Data Store. Reference via {{var.api_key}}. Never write the literal key in URL or body.
Not handling pagination
What goes wrong: API returns 100 records per call (default page size). You assume the response has all data. Real data has 1,000 records — you only see the first 100. Missing 90% of records, silently.
How to avoid: Read API docs for pagination markers (next_cursor, page=2, etc.). Implement a Repeater module that loops until no more pages. Test against an account known to have >100 records.
Wrong Content-Type header
What goes wrong: API expects application/json but you sent application/x-www-form-urlencoded. API parses incorrectly or returns 415 Unsupported Media Type. Hours wasted debugging request body when the header was wrong.
How to avoid: Match Content-Type to body format exactly. JSON body → application/json. Form body → application/x-www-form-urlencoded. Multipart → multipart/form-data.
Ignoring rate-limit responses
What goes wrong: API returns 429 (Too Many Requests). HTTP module errors out, scenario stops, no retry. You discover the issue when too many scenarios pile up.
How to avoid: Add error handler on HTTP module. On 429, parse Retry-After header, Sleep that many seconds, then retry. Implement backoff for repeated 429s.
Not testing the request with curl first
What goes wrong: Spend hours debugging Make-specific quirks when the underlying request is wrong. Could have caught it in 5 minutes with curl.
How to avoid: For any complex HTTP integration: curl test first. Once curl returns the right response, port to Make. Splits problem domains: API issue vs Make config issue.
Recap
Done — what's next
How to set up error handlers in Make.com
Read the next tutorial
Hand it off
HTTP modules are the universal Make connector. A specialist who has integrated 50+ APIs has the patterns memorized — auth, pagination, errors, rate limits. From $14-16/hr — most HTTP integration projects land at $200-500 per API.
See specialist rates
Native module if Make has one for your service — it handles auth, pagination, and error patterns automatically. HTTP module when no native exists, you need a specific endpoint the native module does not expose, or you want more control.
Use 'Make an OAuth 2.0 Request' (separate HTTP module variant). Make manages the token refresh flow. For simple Bearer-token APIs, use 'Make a Request' with a Header. For full OAuth flows, prefer a native Make Connection if available.
Set Body Type = 'multipart/form-data.' Add a field with type 'File' and reference the upstream file binary. Set Content-Type automatically via multipart selection.
Make tried to parse the response as JSON but it is not valid JSON (HTML error page, plain text, empty response, etc.). Check the raw response in the output bundle. If non-JSON, set 'Parse Response' to 'No' and handle manually.
Yes. Method = POST, URL = the GraphQL endpoint, Content-Type = application/json, Body = {"query": "your_graphql_query_here", "variables": {...}}. Standard GraphQL-over-HTTP.
Make
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Make
Iterators and aggregators are how scenarios handle arrays — looping through records, batching API calls, building emails from lists. Get these wrong and one scenario can burn your entire monthly operations budget.
Make
Data Stores are Make's built-in persistent storage. Scenarios are stateless by default; Data Stores give you memory across runs. This is the difference between toy automation and production infrastructure.
Make
Your scenario was working. Now it is failing. The diagnosis sequence specialists run is rarely random — there is a clear order that finds the root cause faster.