Delivery is at least once. Events can be duplicated or arrive out of order. A 2xx response means your receiver accepted the request. Every other status, redirect, DNS/TLS error, or timeout is an unacknowledged attempt. Prava does not follow redirects. HTTP 410 disables the destination; a destination resolving to private or reserved addresses is also disabled.
Automatic delivery allows at most nine network attempts over 72 hours. Known failures while preparing a request, such as a signing-key or database outage, delay delivery and alert Prava without consuming a receiver attempt or opening a receiver-failure incident. An unknown outcome after dispatch begins still counts because the receiver may have accepted it. Retries use increasing delays with jitter; Retry-After is bounded to six hours and the remaining retry window. Each request has a three-second connect budget and ten-second total budget. Request bodies are limited to 64 KiB. Prava reads at most 4 KiB of response body; a received 2xx remains accepted even if the body is larger or closes early. Verification requires a complete JSON nonce echo within 4 KiB. Return a small 2xx response after durable acceptance.
Use Delivery history to inspect endpoint pause/circuit reasons, open incidents, status, attempt times, HTTP status, safe error category, and the original event body. Ordinary event, delivery and attempt history is retained for 30 days. A fresh replay near that cutoff retains delivery inspection and immutable payload through its 72-hour generation window and any live lease, allowing about 33 days total plus a live lease; it does not receive another 30-day window. New replay eligibility and Events API retention remain 30 days. No raw customer response bodies are shown or logged. Administrators can resolve endpoint problems; developers can replay a retained delivery after verifying and enabling an endpoint subscribed to that event. Replays preserve the event ID/body and create a new delivery generation. Retrying the same delivery and idempotency key returns that original generation even if the endpoint URL has since changed; use a new key for a deliberate replay to a newly verified destination. Expired history cannot be replayed. They cancel pending sibling work, but already transmitted requests cannot be recalled.
To recover events in your own system, call GET /v1/events?cursor=0 using your application secret key. Process each page durably before saving next_cursor. When next_cursor is null, that scan is caught up. For later scans, retain the most recent non-null cursor; replaying the last partial page is safe when you deduplicate by event ID. The cursor follows committed capture order within the environment; gaps from other accounts are normal. Recovery does not expose events from another application. Authenticated retained-event and delivery-history reads remain available while Prava delivery is disabled; configuration and replay mutations are paused.
You can retrieve a retained event with GET /v1/events/{eventId}. Events may exist even when no endpoint was active; newly created endpoints do not automatically receive past events. Beyond the 30-day window, reconcile your payment records through the relevant API.
Pausing prevents new delivery claims. URL changes clear verification, pause delivery, increment the destination revision, and cancel old queued deliveries. The final recheck cannot recall a request already in transit. Deleting cancels outstanding work and removes the endpoint from the active list.
Five consecutive unacknowledged deliveries pause an endpoint for five minutes. Only one request is in flight per endpoint; after the pause, a recovery probe can resume delivery. HTTP 410 or a blocked destination disables it until you repair and reactivate it. Attempts still obey the 72-hour and nine-attempt bounds. Shared limits allow at most two concurrent requests and five claims per second per application across workers, with fair account scheduling.
The Dashboard shows safe incident reasons, next-attempt and acceptance times. Exhaustion incidents identify the failed delivery; an unrelated successful request does not clear them. Successfully replaying that event resolves its exhaustion incident, including after a verified destination replacement. The visible operational view refreshes after 30 seconds and backs off to two minutes while unchanged, with jitter; hidden tabs and one-time secret views do not refresh. Incident notices use current authorized developer/admin contacts with verified primary email addresses; retries recheck access and address. Notices use the transactional email outbox and never go through the failed webhook. A queued notice is retained until the email sender is configured and accepts it; queue acknowledgement does not mean an email has been sent.
