Prepare Signature Checks and Duplicate Handling Before Receiving Make Event Subscriptions

That means the receiving side needs signature checks and duplicate handling before you create a subscription.

How do event subscriptions flow?

Make organization event → subscription filter (All events or selected events) → signed JSON POST → your HTTPS endpoint → retries on failure

The developer documentation says each delivery is an HTTP POST request with a JSON body. Events come at the scenario level and the organization level, and the help article gives scenario creation and scenario run failure as examples. The full list of event types and payload fields is on the Event types pages of the developer documentation.

Who can use it, and on which plans?

Based on the help article. Date checked: 2026-10-17.

On the Teams plan, decide up front what your three subscriptions are for. Deactivated subscriptions still count toward the limit, so a test subscription that is only switched off keeps holding a slot.

In what order do you create a subscription?

1. Go to Org > Utilities > Event subscriptions and click Create event subscription.
2. Enter a name and the receiving URL. It must be a public HTTPS endpoint that accepts POST requests.
3. Use Send test event to confirm the endpoint receives it.
4. Choose All events or specific events. Scenario-level events require choosing at least one team.
5. Click Create. The subscription starts in the Active state.

All events also covers event types added later. If you haven't decided how the receiver should handle unknown events, select only the events you need at first. The developer documentation has a separate page on handling unknown events.

How do you confirm a request came from Make?

Each subscription has a signing secret. You can view it again at any time under Signing secret in the Event subscription details tab. The help article says deliveries follow the Standard Webhooks specification, so you can verify signatures with an existing library.

Verification is optional, but the developer documentation recommends it. Anyone who knows the URL can POST to the same endpoint, so it is safer to drop requests whose signature doesn't match. Check the header names and signature format on the Verify signatures page of the developer documentation, and keep the secret in an environment variable or secrets store, not in code.

How do you handle duplicates and out-of-order events?

Make uses at-least-once delivery, so the same delivery can arrive more than once, and there is no guarantee events arrive in the order they happened. Prepare the receiving side like this.

• Store the unique value attached to each delivery and skip any value you have already processed.
• If order matters, sort by the time recorded in the event rather than by arrival order.
• When a request arrives, respond first and defer heavy processing.

The last item is general webhook practice, not something from the documentation. If a slow response gets a delivery marked as failed, retries are added and duplicates can grow. Decide which field to use as the unique value from the Receive events page of the developer documentation.

What happens when a delivery fails?

The retry rules in the help article are as follows.

• If the first attempt isn't accepted, Make sends it up to 10 more times.
• The wait starts at 30 seconds and doubles each time, reaching 4 hours 16 minutes before the last retry.
• If the last retry also fails, the delivery is marked Failed, and the retry schedule can't be changed.

Adding these up, it takes a little over 8 hours 30 minutes from the first attempt to the last retry. If your endpoint is down for more than half a day, events from that period end up Failed. When failures continue, the subscription status changes to Failing, but Make keeps sending new events, and they keep failing until the endpoint is fixed. The help article doesn't say subscriptions turn off automatically after failures.

What do you check after it goes into production?

The subscription's Logs tab shows each delivery's event type, team, status, response code, and time. Opening a delivery shows the payload, the retry history and responses, and the next retry time while it is Retrying. The help article doesn't say how long logs are kept, so save the payloads of failed deliveries on the receiving side as well. You can resend a Failed delivery manually after setting the subscription back to Active, and that can also send the same event again.

Sources: Make Introducing event subscriptions, Make Event subscriptions, Make Event subscription developer docs. Date checked: 2026-10-17.