STRIPE WEBHOOKS
Stripe webhook 410 Gone — endpoint removed without a heads-up
A 410 tells Stripe the endpoint is permanently gone. Unlike a 500, Stripe treats 410 as intentional removal — repeated 410s accelerate endpoint disablement, and they usually mean someone deleted or renamed the route during a deploy.
Why Stripe webhooks fail silently
Route removed in a refactor
Renaming /api/webhooks to /api/hooks, dropping a controller, or retiring a service leaves Stripe POSTing to a dead route that now returns 404/410.
Environment drift
The Stripe endpoint still points at an old domain or a preview deployment that no longer exists.
Intentional-looking responses
Some frameworks and load balancers return 410 for disabled routes — Stripe reads that as "stop trying."
The fix
- 1
Confirm what the route returns now
curl -X POST your webhook URL. If it’s gone, recreate the route or update the Stripe endpoint URL to the new location.
- 2
Update the endpoint in Stripe
Developers → Webhooks → edit the endpoint URL. Deliveries resume on the next event.
- 3
Deploy without breaking the route
Keep the webhook path stable across refactors, or proxy it — a HookShield ingest URL never changes even when your backend does.
- 4
Replay missed events
Resend critical events from the Dashboard or fetch state via the API for the gap window.
DEAD-MAN'S SWITCH
Never find out about a dead webhook from a customer again
Point Stripe at a HookShield ingest URL. Every delivery is logged, signed, and forwarded — and if pings stop arriving, you're alerted before the silence becomes an incident.