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.
Previews in the Playground
The Playground runs the draft, and by default it only previews destinations — nothing is called or sent:
| Type | The preview shows |
|---|---|
| Fixed reply | The reply, rendered as a chat bubble with its buttons. |
| LLM | The prompt that would be sent: provider, model, the rendered prompt and message. The model isn't called. |
| Webhook, API request, workflow, agent | The exact request — method, URL, headers and body — with every secret shown as ••••. |
| Function | The call your code would make, such as assignToSales({ "email": "ana@acme.com" }). |
[
{
"key": "sales_llm",
"type": "llm",
"status": "preview",
"prompt": {
"provider": "openrouter",
"model": "openai/gpt-5-mini",
"instructions": "You are Acme's sales team. Answer the lead in two sentences, say that a person will follow up today and never quote prices.",
"input": "We need pricing for 500 users and want to start next month."
}
},
{
"key": "create_lead",
"type": "http",
"status": "preview",
"request": {
"method": "POST",
"url": "https://api.crm.example.com/v2/leads?source=lead-qualification",
"headers": { "authorization": "Bearer ••••", "content-type": "application/json" },
"body": "{\"email\": \"ana@acme.com\", \"score\": 0.8414, \"note\": \"Routed to sales by Dcision\"}"
}
}
]Previews use the same rendering as real runs, so they are the place to check URLs, encodings and JSON bodies before anything leaves Dcision. Dcision's own headers — the signature, the delivery ID — are added when a request is really sent.
Run destinations for real
When the decision has destinations, the Playground shows Run destinations for real next to Run decision. Switch it on and the next runs:
- call LLM models and agents in
syncmode, and show their answers; - send webhooks, API requests, workflows and
asyncagent hand-offs, with the usual retries; - mark everything as test:
livemodeisfalsein webhook events, in a workflow'sdcisionobject and in an agent'sdecisionobject, and the app labels the deliveries test mode.
Playground runs aren't billed — an LLM provider still bills its tokens to your key — and they count toward the Playground's limits of 30 runs per minute and 2,000 per day. In the Playground, decision.version is null: it runs the draft.
Test API keys
Calls made with a test key (dcs_test_…) run the deployed version and deliver for real, with livemode: false. Use them for staging and CI against staging receivers. They are billed like live calls — see Live and test keys.
Receivers should check the flag and keep test events out of production systems. API requests carry no livemode field — point them at a staging URL while you test.
Follow what happened
- The Playground's Destinations card updates each delivery while it runs: sending, retrying, delivered or failed, the attempts, the HTTP status and latency, the next attempt and the receiver's error. Resend retries a failed delivery.
- Executions shows the same card for every run, from the API too.
- The decision's Overview counts answers returned, deliveries made, failed and pending, per destination.
- The CLI's
dcision validatelists a schema's destinations, anddcision decide --jsonprints thedestinationsof a response.
Before you go live
Preview the destinations in the Playground with a few real states — one per route — and check every URL, header and body.
Run them for real against staging receivers: verify the signature, deduplicate on the delivery ID and ignore or route livemode: false events.
Deploy, call the endpoint with a test key, then switch your integration to a live key. Watch the decision's Overview for failed destinations.
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.
Destination security and limits
How Dcision protects outgoing requests — https only, SSRF guard, no redirects, secrets — what each destination type sends and stores, who can configure what, and every destination limit.