Make.com Custom API Authentication

The HTTP module in Make.com can call any API on the internet, which also means it gives you no guardrails at all around authentication. Every service does it slightly differently, an API key in a header, a bearer token, full OAuth 2.0, and the module has no idea which one your target expects. Getting this wrong produces the same generic 401 regardless of what actually went wrong, which is exactly why authentication setup is where most first-time HTTP module builds get stuck.

I set this up constantly when connecting Make to an API that does not have a native Make integration, Retell AI being a common one for client builds. This post covers the three authentication patterns you will run into, how to configure each correctly in the HTTP module, and how to actually debug a 401 rather than guessing at it.

Authentication Methods in APIs

Before touching Make, read the target API's own documentation for exactly which authentication method it expects and precisely what header name and format it wants. This single step saves more debugging time than anything else here, since a working authentication setup in Make is really just correctly reproducing what the API's documentation specifies, nothing more.

API Key Authentication

The simplest pattern: a static key sent as a header, commonly named something like X-API-Key or Authorization, or occasionally as a query string parameter rather than a header. In the HTTP module, add it under Headers with the exact key name the API expects, matching capitalization and format precisely, since some APIs are stricter about this than others.

Bearer Token Authentication

A very common variant, where the Authorization header needs a specific format: Authorization: Bearer YOUR_TOKEN, with the word "Bearer" included as part of the header value, not just the raw token by itself. This exact detail, forgetting the word "Bearer" or getting its capitalization wrong, is one of the most frequently reported 401 issues in the Make community, producing an error message specifically stating the Authorization header needs the Bearer scheme even though a token was technically provided. If your API documentation shows a bearer token requirement, the header value in Make needs to read exactly Bearer <token> with a single space between the two.

Basic Authentication

Some APIs still use HTTP Basic Authentication, a username and password combined and base64-encoded into the Authorization header. Make's HTTP module handles this encoding for you if you use the dedicated Basic Auth fields rather than needing to construct the encoded string yourself.

OAuth 2.0

For APIs requiring OAuth 2.0, Make supports setting up a proper OAuth 2.0 connection that handles the full token exchange automatically, including refreshing an expired access token without you needing to manage that manually. This is meaningfully more setup than a static API key or bearer token, since OAuth involves an authorization flow, a token exchange, and typically a refresh mechanism, but once configured, an OAuth connection in Make handles token lifecycle on its own rather than requiring you to manually rotate a token that expires.

For a one-off connection to a specific well-known service, check whether Make already has a native OAuth-based app module for it before building a custom OAuth connection through the generic HTTP module, since a native integration handles the OAuth flow for you entirely.

Adding Headers in Make

Regardless of which authentication method you are implementing, headers in the HTTP module are added as key-value pairs in the Headers section of the module configuration. Double-check for accidental whitespace in either the key or the value, a trailing space copied along with an API key from wherever you retrieved it is invisible in the interface but will cause authentication to fail with no obvious explanation in the error message.

Storing Secrets Safely

Do not hardcode an API key or token directly into the HTTP module's configuration if Make offers a Connection for that specific pattern, since a Connection stores the credential separately and reusably rather than embedding it directly in the scenario's own configuration, which is both safer and easier to update later if the credential ever needs to rotate. For genuinely custom APIs without a native connection type, at minimum keep the credential out of anywhere it would be visible if the scenario's blueprint is ever exported or shared.

Debugging 401 and 403 Errors

401 with a message about a missing or incorrect scheme. Almost always a bearer token missing the literal word "Bearer" in the header value, or a mismatch between what the API documentation specifies and what was actually entered.

401 that seems to happen despite a correct-looking token. Test the exact same request in Postman first, using the identical header name and value you have configured in Make. If it works in Postman and fails in Make, the discrepancy is almost certainly in how the header is actually being sent, whitespace, capitalization, or an extra character introduced somewhere in copying the credential.

403 rather than 401. Generally means authentication itself succeeded but the authenticated credential lacks permission for the specific action being attempted, a different problem from bad credentials, worth checking against the API's documented scopes or permission levels for that key or token.

Works once, then starts failing. For OAuth-based connections, this often points to an expired or revoked token that the automatic refresh mechanism is not handling correctly, worth checking the connection's status directly in Make rather than assuming the scenario logic itself has changed.

Once authentication is working reliably, the same HTTP module setup extends naturally into the broader patterns covered in Make.com HTTP Module Tutorial and Make.com API Pagination Guide for building out a complete integration against a custom API.

If you are trying to connect Make.com to an API without a native integration and authentication is not working the way the documentation suggests it should, that is exactly the kind of scenario work I take on for clients. Book a free 30-minute call and bring the API documentation, and we will get the connection working correctly.

Frequently Asked Questions

How do I authenticate an API in Make.com?

Check the target API's documentation for its exact authentication method, then configure the HTTP module accordingly: an API key or bearer token as a header, Basic Auth using the module's dedicated fields, or a full OAuth 2.0 connection for APIs that require it.

How do I add a bearer token in Make?

Add an Authorization header with the value formatted exactly as Bearer YOUR_TOKEN, including the literal word "Bearer" followed by a single space before the token itself, since omitting it is one of the most common causes of an otherwise unexplained 401.

Can Make.com use OAuth 2.0?

Yes, Make supports building a full OAuth 2.0 connection that handles the authorization flow and token exchange, including automatically refreshing an expired access token, rather than requiring manual token management.

Why am I getting 401 in Make.com?

Most commonly a mismatch between what the API expects and what was actually configured: a missing "Bearer" prefix, an incorrect header name, trailing whitespace in the key or value, or an expired token that has not been refreshed.

Why am I getting 403 in Make.com?

A 403 generally means the request authenticated successfully but the credential does not have permission for the specific action attempted, which is a different problem from bad credentials and worth checking against the API's documented scopes.

Where should API keys be stored in Make?

In a Make Connection where a matching connection type exists, since this stores the credential separately and reusably rather than embedding it directly in the scenario configuration, making it both safer and easier to update if the credential changes.

If you would rather have this connected than connect it yourself, I take on Make.com integration work through Fiverr.