reliability
The New Webhook Reliability Mandate
April 22, 2026
Webhook platforms are tightening the screws. Last week, GoHighLevel sent every Marketplace developer a notice that sounds a lot like one Shopify has had in place for years: if your endpoint can't stay healthy, we'll stop sending you events.
The specifics from GoHighLevel's announcement:
- Webhook URLs receiving more than 10,000 webhooks in a rolling 3-day window are monitored.
- If delivery success falls below 90% in a window, the URL gets flagged and the developer gets a warning email.
- If it fails the next 3-day window too, delivery is temporarily paused.
Shopify's Marketplace rules have long worked the same way. Miss their uptime and response-time thresholds and your app can be suspended from the platform.
This is the new normal. And it puts a lot of teams — especially small teams shipping on Marketplace apps — in a tough spot.
Why staying above 90% is harder than it sounds
A 90% success rate is not a high bar on paper. In practice, endpoints dip below it all the time, and usually not because the underlying code is broken. The common culprits:
- Cold starts and timeouts on serverless functions during traffic spikes.
- A single slow downstream service (a DB write, a third-party API) pulling the whole endpoint's response time up, causing platform-side timeouts.
- Deploy windows where the endpoint returns 5xx for a few minutes.
- Unhandled event types that throw exceptions instead of returning 200.
- Bursty traffic — a popular customer triggers 50,000 events in a minute and your infrastructure can't keep up.
Each of these is a bad day. But on a rolling 3-day window at high volume, a single bad day is often enough to drop you below 90% and get flagged.
What these platforms actually want
Read between the lines of GoHighLevel's email and the guidance is clear:
Return a successful response as quickly as possible. Move longer-running work to asynchronous or background processing. Monitor endpoint health and failures in your logs.
In other words: your webhook endpoint should do two things and two things only — accept the event and acknowledge it fast. Anything else (writing to your DB, calling other APIs, running business logic) should happen asynchronously, after you've already returned a 200.
That's good advice. It's also a decent chunk of infrastructure to build and maintain — a queue, workers, retry logic, dead-letter handling, observability, alerting. Every team that takes webhooks seriously ends up building some version of this.
Or you can point the webhook at ProxyHook and get it for free.
How ProxyHook becomes the endpoint that never gets flagged
ProxyHook is a purpose-built receiver for webhooks. You give the upstream platform (GoHighLevel, Shopify, Stripe, anything) a ProxyHook URL. We accept the event, acknowledge it instantly, and then fan it out to wherever you actually want it to go.
A few specifics on what that buys you:
99.999% uptime, by design
Our ingest layer is built for one job: accepting HTTP requests and returning 200s. No business logic runs on the hot path. No database writes block the response. We run across multiple regions with automatic failover, and our published SLA is 99.999% — about five minutes of downtime per year. That's comfortably above every platform's threshold.
Built for millions of requests per second
Spiky traffic is where most endpoints fall over. ProxyHook's ingest is horizontally scaled and handles bursts without breaking a sweat — we're architected for millions of requests per second at peak. Your customer's Black Friday traffic doesn't become your webhook problem.
Durable buffering between ingest and delivery
Once we acknowledge an event, it's written to a durable queue before we try to deliver it to your downstream systems. If your application is slow, deploying, or momentarily down, ProxyHook keeps retrying with exponential backoff until it succeeds. The upstream platform never sees a failure, because it never sees your application — it only sees us.
Observability you can actually use
Every event shows up in the ProxyHook dashboard with:
- Full request and response logs for both ingest and delivery.
- Timing breakdowns so you can see exactly where latency lives.
- Filtering by event type, status code, destination, and customer.
- Searchable history so you can answer "did this event arrive?" without guessing.
Alerting before the platform flags you
You can set thresholds on delivery success, latency, and volume. If your downstream starts failing, you hear about it from us — not from an email telling you your app has been paused.
Fan-out to multiple destinations
Want the same Shopify webhook to go to your app, a data warehouse, and a Slack channel? Configure it once. ProxyHook delivers to all three in parallel, with independent retry logic for each. No more building an N-way broadcaster.
Pause and resume without breaking upstream
Deploying something risky? Pause delivery to one destination without dropping any events. ProxyHook keeps accepting and buffering. When you resume, everything replays in order. The upstream platform never knows anything happened.
Transform and filter on the way through
Rename fields, drop events that don't match a condition, enrich payloads with data from other sources. Keep your application code focused on business logic instead of webhook plumbing.
The real shift
Platforms like GoHighLevel and Shopify aren't going to loosen these requirements — if anything, thresholds will tighten as webhook volume continues to grow. The question for every team running a Marketplace app or webhook-driven integration is no longer "will we get flagged?" but "when?"
Building your own resilient ingest layer is possible. Buying one that's already built, battle-tested, and carries a 99.999% SLA is faster, cheaper, and frankly a lot less stressful.
Point your webhooks at ProxyHook. Never worry about uptime thresholds again.