Use one endpoint when events are related and one team owns them. Use separate endpoints when owners, risk levels or load differ. Either way, each endpoint needs its own signing secret, signature check and failure alerts, and each should subscribe only to the event types it handles.
What the vendors allow
One payment provider's documentation says you can register and create one endpoint to handle several different event types at the same time, or set up individual endpoints for specific events. It limits you to 16 event destinations. A messaging platform lets you subscribe your app only to the events you want, tied to the OAuth scopes granted at install.
So the choice is yours. Here is how to make it.
Decision guide
| Question | One endpoint | Separate endpoints |
|---|---|---|
| Same team owns all events? | Fits | Not needed |
| Events differ in sensitivity, for example payments versus marketing? | Mixes risk | Fits |
| Very different volumes? | Slow events block fast ones | Fits |
| Need to disable one flow quickly? | Hard, all or nothing | Fits |
| Small team, few event types? | Simple | Extra overhead |
| Strict vendor endpoint limits? | Fits | Watch the cap |
Reasons to split
- Blast radius. If an endpoint is flooded or broken, only its events are affected.
- Least privilege in code. A billing handler needs database access to orders. A notification handler does not.
- Independent secrets. A leak of one signing secret does not allow forged events at the other.
- Independent rotation and disabling. You can pause one without losing the rest.
- Clear ownership. Each team runs its own alerts.
Reasons to keep one
- Less to monitor. One URL, one certificate, one alert.
- Shared parsing and verification code in one place.
- Fewer secrets to rotate.
A middle path: one public gateway that verifies signatures, stores events and routes to internal queues by type. You get a single place for verification and separation after it.
Rules whichever you choose
- Subscribe only to event types you handle. Extra events are extra traffic and extra attack surface.
- Verify signatures on every endpoint. See verifying a signature.
- Respond fast and queue work, as in why endpoints should answer in seconds.
- Keep a list of endpoints, owners and secrets locations. Finding forgotten endpoints later is painful. See how to find webhooks sending your repo events to outside services.
- Remove endpoints for retired features.
A worked example
Picture a small shop with three event families: payments, shipping updates and marketing sign ups. Payments touch money and need careful ordering, duplicate protection and tight alerts. Shipping updates are frequent but low risk. Marketing events are noisy and low value.
Put payments on their own endpoint with its own secret, its own queue and its own on call alert. Let shipping and marketing share a second endpoint, since the same developer owns both and a delay there costs little. If marketing traffic ever floods the shared endpoint, payments keep flowing. If the payments secret leaks, rotating it does not touch the other flow.
Revisit the split when teams or volumes change. Splitting later is easy if you routed by event type from the start.
Where Safeguard fits
Safeguard's asset discovery can help surface integrations and endpoints you forgot to list, and its policies help set review rules for new ones. Start with a free scan.
Quick check
Is one endpoint per event type too many?
Often. Group related events by team and risk instead, and keep within the vendor's endpoint limit.
Can two endpoints share a signing secret?
Vendors usually issue one per endpoint. Keeping them separate limits what a leak can forge.
Sources
- Receive events in your webhook endpoint, Stripe documentation
- Events API, Slack developer documentation
Last reviewed: 19 October 2026.
