Delivery and Recovery

Delivery guarantees

Delivery is at least once. A receiver can see duplicates, and different aggregates can arrive out of order. Return any 2xx response only after durable acceptance, deduplicate on payload id, and maintain the highest processed event.cursor when global ordering matters. Do not assume data.version equals event.aggregateVersion; data is the current read model at delivery time.

RoadOps uses bounded retries with increasing delays for network failures, timeouts, and non-2xx responses. A 429 response honors a valid Retry-After value within the supported retry window. A 410 Gone response suspends the endpoint immediately. After all attempts are exhausted, delivery metadata is retained and the failure is placed on the delivery dead-letter queue for operational visibility. Ten consecutive exhausted deliveries suspend the endpoint.

Delivery operations

Use the Developer Portal to send a signed test event, inspect recent delivery metadata, retry an exhausted or suppressed delivery, or recover a pending delivery after its active queue retry window has elapsed. You can also rotate its signing secret and reactivate a suspended endpoint. Saving a team binding again reactivates it. The API exposes the same operations under /v1/webhooks with webhook:read or webhook:write.

RoadOps stores status, attempt count, response status, compact error code, and timestamps. Response bodies and full delivered payloads are not retained.

Before going live, complete the receiver readiness checklist.