Developer Docs
For subscription support teams using Zendesk, Intercom, or internal agents: call /api/decide for deterministic routing, then run policy checks through MCP or REST notaries.
Decision outputs are operational policy-support signals tied to configured policy state. They are not legal advice.
For teams that already run their own signal or classification layer: use /api/decide as the deterministic resolution gate, then route accepted outcomes into your workflow/action system.
One question in, one deterministic yes | no | tie verdict out, plus request_id for audit linkage.
Use verdicts as deterministic policy-execution inputs with human escalation paths. Do not treat API verdicts as legal advice.
Start with Kickoff Sprint ($1,500 one-time), or move directly to API Starter/Team/Enterprise tiers ($299/$1,199/$3,999 monthly, with 20% annual discount). Queue-in-a-Box is available for non-technical rollout.
Use API mode to launch Decision API intake with prefilled runtime context.
Use one production path for both systems and agents so every action is deterministic and auditable.
Submit ticket intent and context. Store request_id with the ticket or workflow run.
Call the relevant notary (refund, cancel, return, trial) using the routed payload.
Run macro or automation, then persist verdict fields and request_id for QA, disputes, and replay.
# Example (subscription refund workflow)
POST /api/decide -> { "c": "yes", "request_id": "abc123" }
POST refund notary -> { "class": "ALLOWED", "reason": "within window" }
Apply refund macro and store request_id in ticket metadata| Endpoint | Method | Purpose |
|---|---|---|
/api/decide | POST | Return deterministic yes | no | tie for routing decisions with decision_id, request_id, and policy contract hashes. Default guardrail is 20 req/min per API key and is surfaced via x-ratelimit-* headers. |
/api/decision/:id | GET | Fetch a stored decision ledger entry by decision_id. |
/api/decision/:id/replay | POST | Replay the original input through current /api/decide and return a verdict/policy diff summary. |
https://refund.decide.fyi/api/mcp | POST | MCP JSON-RPC for refund eligibility tools/call. |
https://cancel.decide.fyi/api/mcp | POST | MCP JSON-RPC for cancellation penalty checks. |
https://return.decide.fyi/api/mcp | POST | MCP JSON-RPC for return eligibility checks. |
https://trial.decide.fyi/api/mcp | POST | MCP JSON-RPC for trial terms checks. |
Use one canonical path: ticket payload -> /api/decide -> workflow endpoint -> deterministic action + request_id.
curl -X POST https://www.decide.fyi/api/v1/workflows/zendesk/refund \
-H "Content-Type: application/json" \
-d '{
"vendor": "adobe",
"region": "US",
"plan": "individual",
"days_since_purchase": 12,
"ticket_id": "zd-4812"
}'
# response shape
# { "request_id": "...", "action": "refund", "policy_class": "ALLOWED" }const payload = {
vendor: "adobe",
region: "US",
plan: "individual",
days_since_purchase: 12,
ticket_id: "zd-4812"
};
const res = await fetch("https://www.decide.fyi/api/v1/workflows/zendesk/refund", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload)
});
const data = await res.json();
console.log(data.request_id, data.action, data.policy_class);import requests
payload = {
"vendor": "adobe",
"region": "US",
"plan": "individual",
"days_since_purchase": 12,
"ticket_id": "zd-4812"
}
res = requests.post(
"https://www.decide.fyi/api/v1/workflows/zendesk/refund",
json=payload,
timeout=15,
)
data = res.json()
print(data.get("request_id"), data.get("action"), data.get("policy_class"))Run one Decision API call, then replay the same decision_id through /api/decision/:id/replay and inspect verdict/hash drift in one panel.
No replay run yet.
{
"note": "Run replay check to populate."
}Use this exact sequence to move from intake to first live queue traffic without scope drift.
| Window | Owner | Required output |
|---|---|---|
| Day 0-1 | Support ops + decide | Queue selected, baseline KPI formulas frozen, escalation path confirmed. |
| Day 2-3 | Platform/automation engineer | /api/decide wired into one macro/workflow with request_id persistence. |
| Day 4-5 | Policy owner | Notary payload contract validated on sample tickets, exception classes reviewed. |
| Day 6-7 | Support ops + QA | First live-traffic readout, replay checks, and dispute evidence export confirmed. |
Use ops console or /api/proof-metrics to capture pilot intake, delivery rate, and event activity windows.
Confirm escalation-rate and handle-time deltas against the locked baseline, then flag blockers before rollout expansion.
Export CSV + request-linked artifacts for policy owners, QA, and procurement decision threads.
Short answers to common implementation and commercial blockers.
No. Alert feed counts reflect confirmed semantic policy changes, not generic page churn.
Yes. Runtime-only commercial scope is available if you do not need rollout workflow services.
Kickoff Sprint with one scoped queue, then Queue-in-a-Box or API rollout after KPI and evidence review.
Yes. Use one canonical workflow so both paths consume the same deterministic verdict and request_id evidence.
Users return to /payment/success and receive kickoff details by email. If no message after 10 minutes, check spam/promotions and contact support.
Use live demo + audit trail to validate payloads, response shape, and replay behavior before rollout.
| Route | Use | Readiness dependency |
|---|---|---|
/api/runtime-config |
Front-end runtime/commercial readiness config. | Payment links, booking URL, pilot confirmation channel. |
/api/pilot |
Pilot intake submission + confirmation trigger. | Webhook destination and confirmation provider config. |
/api/proof-metrics |
Pilot and activity snapshot used by proof/ops views. | x-metrics-token for protected reads. |
/api/pilot-export |
CSV export for rollout review and evidence packs. | Metrics token + proof metrics data availability. |
/api/stripe-webhook |
Stripe checkout lifecycle events (checkout.session.*) for payment-complete tracking. |
STRIPE_WEBHOOK_SIGNING_SECRET in production. |
/docs.json contains endpoint, schema, and rate-limit metadata.
/vendors and /vendors.json list all supported vendors plus policy source links by workflow.
/rules/policy-sources.json and category-specific variants for policy provenance checks.
/resources/policy-alerts and /api/policy-alerts for daily policy change signal alerts with confidence labels.
Use live demo + audit trail to validate payloads, responses, and replay behavior.
Share /resources/security with procurement and security reviewers during pilot intake.
Use /payment/success and /payment/cancel as Stripe post-checkout return destinations.