Skip to main content
Pre-release — contact your Fortary account team for access.

​
What counts as delivered

A delivery succeeds when your endpoint returns any 2xx status within 10 seconds. Anything else — another status code, a timeout, a TLS or connection error — is a failed attempt.
  • Redirects are not followed.
  • Your response body is read up to 1 KB and stored as a diagnostic snippet, visible in the delivery history.

​
Retry schedule

Failed deliveries are retried with growing spacing (each delay carries ±20% jitter):
AttemptDelay after previous attempt
1immediate — when the event occurs
25 s
330 s
42 min
510 min
630 min
71 h
82 h
94 h
106 h
11+every ~6 h
Retries continue for 24 hours from the first attempt (about 12 attempts). A delivery that never succeeds is marked exhausted — it remains visible in the delivery history and can be redelivered manually. If your endpoint is overloaded, include a Retry-After header (in seconds) on your failure response — typically with a 429: the next retry honors it, up to a maximum of 1 hour.

​
Automatic disabling

When a delivery exhausts its 24-hour budget as the 10th consecutive exhausted delivery and the webhook has had no successful delivery in 72 hours, the webhook is disabled and Fortary emails its notification address. To recover:
  1. Fix your endpoint, and verify it with a test ping — pings work while the webhook is disabled.
  2. Re-enable the webhook (this resets the failure counter).
  3. Events that occurred while disabled are not delivered retroactively — no deliveries exist for them to redeliver. They remain browsable in the event log (31-day retention) for manual reconciliation.

​
Redelivery

Any delivery can be redelivered. A redelivery is a fresh delivery: new x-fortary-delivery-id, attempt counter restarted, a full new retry budget, signed with the webhook’s current secret. The event body is byte-identical to the original.

​
Handling deliveries reliably

  • Acknowledge fast, process async. The 10-second window is for receipt, not processing.
  • Deduplicate on the event id. Retries and redeliveries can hand you the same event twice.
  • Don’t rely on ordering. Order by the envelope’s date when sequence matters.
  • Tolerate unknown fields. Additive payload changes ship under the same schemaVersion.
  • Alert on signature failures. They mean a secret mismatch or traffic that isn’t from Fortary.