Delivery and retries
How Dcision delivers webhooks, API requests, workflows and agent hand-offs — at least once, six attempts over about seven hours, Retry-After, timeouts, statuses, resends and retention.
Webhooks, API requests, workflows and agents in async mode are deliveries: the decision answers first, and Dcision sends them in the background. The response tells you what was queued:
{ "key": "notify_sales", "type": "webhook", "status": "queued", "delivery_id": "dlv_8kJx2mQp4LzN7vR1tY6w" }At least once
A delivery is sent at least once. A receiver that times out or loses its answer gets the same delivery again, so make receivers idempotent with the delivery ID — the same on every attempt and on resends:
| Type | Where the delivery ID is |
|---|---|
| All | The Dcision-Delivery header. |
webhook | The event's id. |
http, workflow, agent | The Idempotency-Key header (unless you set your own); dcision.delivery_id in workflows, decision.delivery_id for agents. |
Deliveries aren't ordered: two deliveries of the same decision — or of two decisions — can arrive in any order.
Attempts
| Attempt | When |
|---|---|
| 1 | immediately |
| 2 | 30 seconds after the first attempt |
| 3 | 2 minutes after the second |
| 4 | 10 minutes after the third |
| 5 | 1 hour after the fourth |
| 6 | 6 hours after the fifth |
That is 6 attempts over about 7 hours. The Dcision-Attempt header says which one a request is, and every attempt is signed again with a fresh timestamp.
| The receiver… | Outcome |
|---|---|
answers 2xx | Delivered. |
answers 408, 425, 429 or 5xx, times out or can't be reached | Retried on the schedule above. With 429 or 503, a Retry-After header — in seconds or as a date — sets the wait instead, from 1 second up to 6 hours. |
answers any other 4xx | Failed at once: fix the destination, then resend. |
answers a redirect (3xx) | Failed at once: redirects are never followed — use the final URL. |
| resolves to an address that isn't public, or the URL is invalid once variables are filled in | Failed at once — see Security and limits. |
Each attempt has a 10-second deadline. Dcision reads up to 64 KB of the answer and keeps its status code, the latency and its first 1,024 characters, which the app shows next to the delivery.
Statuses
| Status | In the app | Meaning |
|---|---|---|
PENDING | sending · retrying | Waiting for its next attempt. |
SENDING | sending | An attempt is in flight. An attempt interrupted by a restart is picked up again after 60 seconds. |
SUCCEEDED | delivered | A 2xx answer. |
FAILED | failed | A final failure, or 6 attempts without success. |
Where to follow them:
- The Playground result and an execution's details in Executions show each destination with its live status, the attempts, the HTTP status and latency, the next attempt and the error — and test mode for
livemode: falsedeliveries. - The decision's Overview counts delivered, failed and pending deliveries per destination.
Everyone in the workspace can see deliveries; the app never shows their body — only a masked preview of the request.
Resend a failed delivery
Resend on a failed delivery (Members, Admins and the Owner) queues it again with 6 new attempts and the same delivery ID, so a receiver that did process it can still deduplicate.
The rendered request — with its secrets — is stored encrypted while a delivery may need it: it is deleted when the delivery succeeds and kept for failed ones, so they can be resent. A resend sends that same request: a change to the destination or to a secret applies to new runs of the decision, not to resends.
Pace and limits
- A workspace sends up to 600 deliveries per minute. Deliveries above that wait for the next minute without using an attempt.
- The response doesn't wait for deliveries: they are queued with the run and start at once, in the background.
- If a delivery can't be queued at all (the queue is unavailable), its entry says
"status": "skipped", "reason": "unavailable", and the decision still answers.
Retention
Finished deliveries — succeeded or failed — are deleted 30 days after they were created, whatever the workspace's execution log retention. Deleting a decision doesn't cancel deliveries already queued: they finish their attempts and expire with the others. Deleting the workspace deletes them all.
Idempotency and replays
- An idempotent replay returns the stored response with the same delivery IDs, and nothing is delivered again.
- A request that is still running with the same
Idempotency-Keygets409withRetry-After: 1— it never runs, or delivers, twice. - An engine-error fallback isn't stored for idempotency: a retry runs the decision again and queues new deliveries, with new IDs.
Workspace secrets
Keep tokens and secret URLs out of decisions — workspace secrets referenced as {{secrets.NAME}}, who can manage them, how they are stored and masked, and when changes apply.
Testing destinations
Preview destinations in the Playground with secrets masked, run them for real with livemode false, use test API keys and follow deliveries, attempts and receiver answers.