QUANTIN / DOCUMENTATION

Quantin Events and Webhooks: Verification, Delivery and Retries

A webhook implementation guide for signature verification, fast acknowledgements, duplicate delivery, retries, ordering, and replay protection.

Webhooks allow an application to react to Quantin lifecycle events without repeatedly polling. A production receiver must assume that delivery is asynchronous, may be repeated, and may arrive out of order.

Verify every request

Validate the webhook signature against the raw request body using the secret configured for the endpoint. Reject invalid signatures and timestamps outside the accepted tolerance. Keep current and previous secrets available briefly during a planned rotation.

Acknowledge quickly

Return a successful response after verification and durable queueing. Perform business processing asynchronously. Slow synchronous work increases retries and can create duplicate effects.

Deduplicate by event ID

Store processed event identifiers for the required retention period. If the same event arrives again, return success without repeating the downstream action. Event deduplication and action idempotency should both be present.

Do not depend on delivery order

Compare event occurrence time and resource version before updating local state. If an event refers to an unfamiliar resource or appears older than current state, retrieve the latest authorized representation before deciding what to do.

Handle retries

Temporary endpoint failures may produce repeated delivery attempts. Monitor delivery age and failure count, and provide an operator path to replay events after an outage. Permanent validation failures should be investigated rather than retried indefinitely.

Receiver checklist

  • HTTPS endpoint with a valid certificate.
  • Raw-body signature verification.
  • Timestamp tolerance and replay protection.
  • Durable queue before acknowledgement.
  • Event-ID deduplication.
  • Idempotent downstream actions.
  • Delivery monitoring and replay procedure.

Webhook reliability comes from treating delivery as an event stream, not as a one-time command.