Connect a website backend to a Make custom webhook

Accept the request in the website backend first

Validate the form on the site’s server and durably save an intake ID and pending-delivery state before forwarding to Make. That keeps a slow downstream response from erasing the original request. Return the site’s own receipt to the browser without exposing the Make URL or API key.

Define an event contract

A fictional JSON event has event_id TEST-WH001, event_type inquiry.created, occurred_at 2026-10-29T09:00:00Z, schema_version 1 and category setup. Keep the body minimal. Reuse the same event_id when retrying the same event. Specify required fields, types, length limits and allowed event values on both sides.

Create an authenticated Custom webhook

Add Webhooks > Custom webhook and configure API Key authentication. The backend sends the key in x-make-apikey over HTTPS. Store the URL and key in server-side secret settings, never public code, browser environment variables, screenshots or request logs. Assign an owner and rotation procedure for those credentials.

Validate with an explicit data structure

Choose a defined Data structure in Advanced settings. Detecting fields from a sample request alone does not establish incoming validation. Also check allowed event_type and schema_version values with a filter. Do not allow caller-supplied category text to choose arbitrary storage targets or notification recipients.

Use event identity in durable storage

Select storage that can enforce a unique event_id and record stages such as received, notified and failed. Concurrent deliveries may require a database uniqueness constraint or another suitable atomic mechanism. Searching a sheet and then appending is vulnerable to a race. Keep destinations fixed and associate the returned message ID with the event.

Separate acceptance from business completion

The default Accepted response can represent queue acceptance rather than a completed save or notification. A later Webhook response still needs timeout and failure handling. Keep the website’s transport record separate from the business-completion record and reconcile through an authenticated status check or completion callback when that evidence is required.

Implement bounded retries and ordering rules

Retain pending events and retry transient failures or rate limits with bounded delay. HTTP 400 with body Queue is full indicates queue saturation, unlike invalid-input rejection; inspect the response rather than treating every 400 alike. Correct validation errors before resending. Instant webhook executions run in parallel by default; consider Process data in order when needed. It does not provide global deduplication or exactly-once completion.

Check responses and side effects together

Test a valid event, missing authentication, missing required data and a replay of the same event_id. Inspect storage count, notification count and stage records as well as HTTP responses. Include a failure after notification but before state recording. Remove practice URLs and keys from published material and define monitoring, retention and a recovery owner before production.

• Understand unique keys and partial success
• Recover from execution history
• Use a form-response sheet for a simpler notification