Make · Help

Make Custom Webhook returns Unauthorized?

Opening a webhook URL returns Unauthorized? Check its API-key header, IP rules and actual hook identity without removing protection.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Unauthorized when directly opening a Make webhook can mean access control is working correctly. If API-key authentication is configured, Make expects the key in x-make-apikey; ordinary address-bar navigation does not automatically send it. First compare the actual hook URL and protection settings with the intended sender's request. Then test a harmless authorised request and an unauthorised control while keeping the configured protection enabled.

Source basis: Q1 · Q2

Applies to
Applies to Make Custom Webhooks with optional API-key authentication and possible IP restrictions. Establish which rules are configured on the exact hook in use.
How to verify the result
The intended authorised test is accepted and processes the expected record; a request without permission remains rejected while configured access controls stay enabled.
Your first check

Does the real sender supply the API-key header configured for this hook?

You create a Custom Webhook in Make, paste its URL into a browser and receive Unauthorized. That can be an access control working as intended. The important question is whether the real sender includes the credentials configured for this particular hook.

Distinguish browser navigation from an authorised request

An original report describes the error when opening the URL directly. Q1 Make documents optional API-key authentication for Custom Webhooks: the key is supplied through the x-make-apikey header. IP restrictions can also apply. Q2 A normal address-bar navigation does not include a custom header you configured for an integration.

This symptom is therefore insufficient reason to recreate the hook or remove its authentication. First compare the URL, protection settings and actual request from the intended sender.

Check access systematically

  1. Identify the correct hook. Compare organisation, team, scenario and the currently selected webhook connection. An older copied URL may refer to a different hook.
  2. Read active access rules. Establish whether API-key authentication and IP restrictions are configured. Record their presence and responsible identity without publishing the secret key.
  3. Inspect sender configuration. Does the actual service support custom headers? Is it sending x-make-apikey with the intended value from secure storage? A key placed in the URL or JSON body does not substitute for that header.
  4. Isolate a harmless request. Use a test route without downstream external writes. Against the same URL, compare an appropriately authorised request with an unauthorised one. The expected result is a deliberate difference in access.
  5. If it still fails, compare sources. Check allowed IP ranges against the sender's actual infrastructure. A successful laptop test can originate from a different address than the production service.

After the request is accepted

Separately verify the payload shape and whether the scenario processes the intended test record. HTTP acceptance does not establish success across every subsequent module. Record responsibility for key rotation because changing the key may affect more than one sending system.

For a handover, provide the redacted hook identity, timestamp, response status, configured authentication type and whether the actual sender supports the required header. Do not include the full secret URL or key in a public ticket.

Frequently asked questions

Should I remove the key so the browser works?

No. Test the configured authentication using a suitable client. The endpoint does not need weaker protection to accommodate an incomplete browser request.

Why is the key absent from the received data?

Make handles this reserved header specially and sanitises its value in the displayed payload. Q2 Use acceptance status and a controlled comparison instead of copying the secret into another visible field.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0336 with KAN KAI WORKS.

Support with this issue

We investigate Make using your error message, versions and a narrowly scoped example.

Describe your case →Related service: AI & automation

Sources

Sources checked on 5 November 2026. Individual reports do not establish general prevalence.