A Custom Webhook module in Make gives you an HTTP endpoint that, when called, starts a scenario execution with the request body as input. It's the fastest path to a real-time ERP integration — an order placed on a storefront hits the webhook, the scenario runs immediately instead of waiting for a poll cycle. The convenience hides a few things that need deliberate handling once real traffic and real failures show up.
Webhooks are at-least-once delivery, not exactly-once
Whatever is calling your Make webhook — a payment provider, an e-commerce platform, the ERP itself — will typically retry on timeout or non-2xx response. That means the same event can arrive twice, and a scenario that isn't written to expect that will double-process it: two sales orders for one purchase, an inventory adjustment applied twice. Every webhook-triggered scenario that writes to the ERP needs a dedup check (a Data Store keyed on the event's unique ID) before the write, not as an afterthought.
{
"flow": [
{"module": "webhook:CustomWebhook", "name": "Order Event"},
{"module": "datastore:ActionGetRecord", "name": "Check event_id seen"},
{"module": "flow:filter", "condition": "{{2.value}} is empty"},
{"module": "datastore:ActionAddReplaceRecord", "name": "Mark event_id seen"},
{"module": "http:ActionSendData", "name": "Write to ERP"}
]
}Respond fast, process slow
Most webhook senders expect a response within a short window (often a few seconds) and will treat a slow response as a failure worth retrying, even if your scenario eventually would have succeeded. If the ERP write itself is slow, acknowledge the webhook immediately and hand the actual processing to a queued follow-up (Make's own scenario-to-scenario triggering, or writing to a queue the ERP write reads from), rather than making the sender wait on the full round trip.
A public webhook URL will occasionally receive malformed, incomplete, or actively malicious payloads — scanners probe webhook endpoints constantly. Verify the sender's signature if the platform provides one, and validate required fields exist before the scenario tries to use them, or a scenario failure from bad input becomes the routine case instead of the rare one.
Treat the webhook URL like a credential
Make's custom webhook URLs are unguessable but not secret once shared, logged, or embedded in a third party's config screen. Where the sending platform supports HMAC signatures on webhook payloads (Stripe, Shopify, and most modern platforms do), verify the signature in the scenario before acting on the payload — an unguessable URL is not the same guarantee as a verified sender.
Bursts queue, they don't get dropped, but the queue has a size
Make queues incoming webhook calls when scenario runs can't keep up momentarily, which handles small bursts gracefully. Sustained high-volume bursts (a flash sale, a bulk re-import from the source system) can still back the queue up faster than the scenario drains it, and the practical effect is growing latency between the webhook firing and the scenario actually processing it — worth monitoring if the business depends on near-real-time behavior specifically.
Even a well-built webhook flow benefits from a slower scheduled scenario that catches anything the webhook path missed — a delivery that failed silently upstream, an event the sender never fired. Real-time and eventual-consistency approaches aren't competitors here; the second one is insurance for the first.
Wrapping up
A Custom Webhook trigger makes real-time ERP integration straightforward to wire up, but at-least-once delivery, slow senders that time out, and unauthenticated public endpoints are all things Make hands you responsibility for, not things it solves by default. Dedup on a unique event ID, acknowledge quickly and process asynchronously where the ERP write is slow, and verify sender signatures where the platform offers them.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.