This guide explains how zerohash can deliver every webhook notification to more than one listener endpoint, so a platform running redundant or disaster-recovery listeners can keep each one fed from the same event stream.
Why multiple endpoints
A platform has a single webhook URL by default, which makes that listener a single point of failure. If it is unreachable, the platform depends entirely on retries and on recovering state out of band. A platform that runs listeners in more than one site also cannot keep both sides in sync from one delivery target.
With multiple endpoints configured, every webhook the platform is subscribed to is delivered independently to each endpoint. Payloads and headers are identical on every copy, so each listener can write to its own store and the platform can reconcile across them.
This is optional. A platform that does not configure additional endpoints continues to receive one webhook per event at its default URL, exactly as today.
When to use it
- Disaster-recovery listeners. A primary site and a standby site each receive the full stream, so a site failover needs no replay from zerohash.
- Independent consumers. Separate internal systems consume the same events without one of them relaying to the other.
- Staged cutover. Run a new listener alongside the existing one and compare, before retiring the old target.
Configuration
Endpoints are configured by zerohash, not through the public API. Contact your zerohash representative with, for each endpoint:
| Field | Description |
|---|---|
| Label | A short name used operationally, for example primary or DR site B |
| Address | The HTTPS URL that receives the webhook POST |
| Enabled | Whether the endpoint currently receives deliveries |
Your existing webhook URL remains in place as the default webhook URL and is still required.
Delivery behavior
- Every enabled endpoint receives every webhook type the platform has opted into. Event filtering per endpoint is not supported.
- Each endpoint gets its own copy of the notification. Delivery, retry and give-up are tracked separately per endpoint.
- Payloads are byte-identical across endpoints, and so are the
x-zh-hook-*headers, includingx-zh-hook-notification-id. - A disabled endpoint receives nothing. Endpoints can be disabled and re-enabled without being removed.
Authentication
Authentication is configured per platform, not per endpoint. Every endpoint receives webhooks authenticated the same way as the default URL: the same signing scheme and the same credentials. If your platform uses RSA or HMAC request signing, each endpoint must verify signatures using the same key material. See Webhook Security for the header and verification detail.
Distinct credentials per endpoint are not supported.
Deduplication
Because every endpoint receives the same notification with the same x-zh-hook-notification-id, that value identifies the event, not the delivery. Two listeners writing to a shared store must deduplicate on it, or they will each apply the same event.
If each listener writes to its own store, treat the notification id as the join key when reconciling between them.
Retries and failure handling
Each endpoint's copy follows the normal retry policy on its own: up to 8 attempts, four fast retries followed by exponential backoff, over roughly seven minutes.
- A failing or slow endpoint does not delay, suppress or duplicate delivery to the others.
- A healthy endpoint is never redelivered because a sibling endpoint failed.
- When an endpoint exhausts its retries, that copy is dropped. Other endpoints are unaffected, so in a redundant setup the event is still available from the listener that succeeded.
- A copy whose endpoint is removed or disabled between publish and delivery is dropped without further attempts.
Recovering a dropped event still requires reading the relevant resource back from the API. zerohash does not replay webhooks on request.
Limits and rules
- Up to 5 endpoints per platform, including the default URL.
- Addresses must be valid HTTPS URLs and unique within the platform.
- Every endpoint receives every opted-in event type.
- All endpoints may be disabled at once. The platform then receives no webhooks while fan-out is on; this is allowed and is not treated as an error.
- Reverting to single delivery is a configuration change on the zerohash side; saved endpoints are retained, so fan-out can be restored without reconfiguring them.
Capacity planning
Fan-out multiplies outbound volume by the number of enabled endpoints. Size each listener for the full event rate, not a share of it, and confirm any inbound rate limits on your side allow for the full stream per endpoint.
Support
To add, change, disable or remove endpoints, or to check delivery against a specific endpoint, contact your zerohash representative. Per-endpoint delivery status is not exposed through the API today; zerohash can report on it from internal monitoring on request.