Decision API before software acts

Decision API before software acts.

Send action context. Get yes, no, or review with a replayable Decision Record before your product, agent, queue, or internal tool changes state.

Request API access Run sandbox
POST /api/decide 200 record created
$ curl -X POST https://decide.fyi/api/decide -d @pricing_exception.json

Request

{
  "mode": "rulebook",
  "rulebook": {
    "schema_version": "rulebook_v1",
    "rulebook_id": "pricing_exception",
    "version": "2026-06-11",
    "rules": [{
      "rule_id": "approve_standard_exception",
      "priority": 100,
      "condition": {
        "all": [
          { "field": "discount_percent", "operator": "lte", "value": 15 },
          { "field": "margin_floor_passed", "operator": "eq", "value": true },
          { "field": "owner_verified", "operator": "eq", "value": true }
        ]
      },
      "outcome": {
        "decision": "yes",
        "verdict": "APPROVE",
        "action": "approve_discount",
        "reason_code": "STANDARD_EXCEPTION_ALLOWED"
      }
    }],
    "default_outcome": {
      "decision": "review",
      "verdict": "REVIEW",
      "action": "route_to_owner",
      "reason_code": "NO_RULE_MATCHED"
    }
  },
  "context": {
    "workflow": "pricing_exception",
    "source_record_id": "deal_1042",
    "requested_action": "approve_discount",
    "inputs": {
      "discount_percent": 15,
      "margin_floor_passed": true,
      "owner_verified": true
    }
  }
}

Response

{
  "decision_record_version": "decision_record_v1",
  "verdict": "yes",
  "application_verdict": "APPROVE",
  "reason_code": "STANDARD_EXCEPTION_ALLOWED",
  "matched_rule_id": "approve_standard_exception",
  "request_id": "req_9f3c",
  "decision_id": "dec_43b2",
  "evidence": ["STANDARD_EXCEPTION_ALLOWED"],
  "action": "approve_discount",
  "action_binding": {
    "system": "pricing_exception",
    "resource": "deal_1042",
    "proposed_action": "approve_discount"
  },
  "policy_id": "pricing_exception",
  "policy_version": "2026-06-11",
  "rulebook": {
    "schema_version": "rulebook_v1",
    "id": "pricing_exception",
    "version": "2026-06-11",
    "hash": "4cf1..."
  },
  "policy_bundle_hash": "4cf1...",
  "record_hash": "7f3a...",
  "receipt_hash": "c91e...",
  "verify_url": "/api/decision/dec_43b2/verify",
  "replay_url": "/api/decision/dec_43b2/replay"
}
API docs Run sandbox Pricing proof
Input context + guardrails Verdict yes / no / review Record decision_id + hash Execute receipt + state hash Outcome result + metrics Intel score + anomalies
Runtime boundary Declarative core. Trusted facts. No customer executable rulebooks.
Runtime contract

Your app sends action context; Decide returns the verdict record before anything changes state. Legacy single, multi, and runtime calls are advisory-only. Underneath, the production core is hybrid_declarative_rulebook_with_trusted_adapters: direct calls use direct_declarative_rulebook; registered trusted adapters use trusted_adapter_facts_then_declarative_rulebook.

Verdict authority declarative Rulebook v1 declarative Rulebook v1 remains the verdict authority. Adapter authority facts_only trusted adapters emit facts only before Rulebook v1 evaluates. Rejected mode customer_executable_rulebook Fails closed with RULEBOOK_BINDING_MODE_UNSUPPORTED. No caller-supplied verdicts decision_contract Callers cannot preload the verdict, decision_contract, or runtime material; those requests fail with RULEBOOK_OUTPUT_MATERIAL_FORBIDDEN.
Read runtime docs Read application binding
Interactive API proof

Run the sandbox before you integrate.

Try the pricing-exception boundary, inspect the returned record shape, then copy cURL, JavaScript, or Python when the shape fits. Binding production verdicts use Rulebook v1.

1 Test an action 2 Inspect the record 3 Copy integration
Request

Action boundary

POST /api/decide
Input shape
Return mode
Sandbox single: ask one non-binding question and get yes, no, or review.

Sandbox calls are for integration design. Binding production verdicts use mode: "rulebook" with Rulebook v1. Production keys add auth, quotas, telemetry, replay visibility, and commercial controls.

Try a preset

Each preset changes the action context sent to the Decision API.

Response

Decision record

Run a request A completed record includes verification and replay paths.
What returns Waiting
No Decision Record yet

Run a preset or enter an action boundary to inspect the returned record.

Verdictyes / no / review Identitydecision_id + request_id Proofevidence + record_hash Follow-upverify_url + replay_url
Integration handoff No request run yet - try a preset above
The sandbox uses shared demo limits. Production access adds keyed calls, quotas, telemetry, replay visibility, and commercial controls.

What makes it production-grade.

The value is not a prettier form. It is the repeatable API boundary between a verdict, its evidence, and the action that follows.

Deterministic verdict

The same canonical input and Rulebook v1 version return the same verdict: yes, no, or review.

Replay handle

Every call gets a replay URL and durable record hash so teams can inspect, rerun, and attach outcomes.

Stateless input

Each request is scoped to current context, so old chat drift does not leak into production decisions.

Integration-ready

Response fields are compact and easy to route into products, automations, queues, agents, and MCP tools.

Reference proof apps

Reference applications show how the same primitive gates source-backed policy, pricing, and execution workflows.

Flagship proof run

The risky moment is CRM or billing changing state before margin, owner, and evidence checks are attached.

Approve a pricing exception before CRM or billing changes.

Input

Discount exception

Approve a 15% annual-plan discount for a growth account?

  • Owner: RevOps
  • System: CRM + billing
  • Risk: margin change without an owner trail
Checks

Guardrails

Decide checks the facts that usually live across CRM fields, policy docs, and human review.

  • Margin floor passed
  • Owner rule verified
  • Evidence quality sufficient
Output

Decision Record v1

{
  "verdict": "yes",
  "application_verdict": "APPROVE",
  "decision_id": "dec_43b2",
  "evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
  "action": "approve_discount",
  "policy_version": "2026-06-11",
  "record_hash": "7f3a...",
  "verify_url": "/api/decision/dec_43b2/verify",
  "replay_url": "/api/decision/dec_43b2/replay"
}
Replay artifact dec_43b2 can be replayed against pricing_exception:v3.

Replay compares verdict, evidence, and record hash against the original policy run instead of screenshots, chat history, or memory.

First wedge

Prove it first where mistakes are expensive.

Pricing exceptions make the first boundary obvious: revenue is at stake, ownership is clear, and the record must travel with the action.

Margin risk A wrong exception changes revenue. Clear owner RevOps already owns the boundary. Expansion path The same record can gate any state change.
Run sandbox View proof artifact Read API docs

Decision API

One call. Stable result.

Decide should feel like infrastructure, not another dashboard. Send context and guardrails, then receive yes, no, or review with a decision record your system can store, replay, and attach to the action that follows.

Same input + rulebook, same verdict Policy version stays attached Replay exposes verdict drift
Decision Record v1record_hash
{
  "endpoint": "/api/decide",
  "request": {
    "mode": "rulebook",
    "binding_mode": "direct_declarative_rulebook",
    "action": "approve_discount",
    "context": { "discount_percent": 15 },
    "rulebook": "pricing_exception:v3"
  },
  "response": {
    "verdict": "yes", "decision_id": "dec_43b2",
    "evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
    "runtime_binding": { "verdict_authority": "declarative_rulebook" },
    "rulebook_contract": { "evaluator_version": "decide_rulebook_v1" },
    "record_hash": "7f3a...",
    "replay": "/api/decision/dec_43b2/replay"
  }
}

How it matures

Decide. Prove. Learn.

Start with one recorded verdict. Add execution and outcome evidence only when the boundary becomes production-critical.

01 · Decide

Return one recorded verdict.

Context and guardrails become yes, no, or review with evidence before state changes.

02 · Prove

Attach what happened.

Execution Receipts and a portable Decision Packet connect the verdict to the attempted action.

03 · Learn

Improve the boundary.

Outcome Records measure rule effectiveness, confidence, benchmarks, and explainable anomalies.

Explore the full lifecycle

Why not hard-code this?

Rules in one app are easy. Proof across systems is the hard part.

Software is acting faster than teams can audit. Decide gives each bounded action one recorded verdict that survives outside the code path that made it.

Before Decide

The approval lived everywhere.

Slack, CRM notes, workflow branches, and logs each held part of the rule.

After Decide

Every exception has a verdict and record.

Evidence, policy version, hashes, verify URL, and replay URL stay beside the action.

Example operating change

Review becomes a lookup, not archaeology.

RevOps can inspect the record, attempted execution, and outcome without reconstructing intent.

Production questions

What changes when this goes live?

Keep the workflow. Add one call before the state change and store the record beside the action.

Does Decide replace my workflow?

No. It sits before the CRM, billing system, queue, agent, or internal tool changes state.

What does my system store?

Decision Record v1: verdict, evidence, policy version, hashes, verify and replay URLs, and the action that followed.

What happens on review or no?

Your product routes, holds, or blocks using the same verdict and record.

What does access add?

Keyed API calls, quotas, telemetry, replay visibility, security docs, and launch support by plan.

From sandbox to production.

Start with one production boundary. Developers can wire the record; buyers can approve the controls.

Developer path

Make one call. Store one record.

Shape the request in sandbox, then use the quickstart and SDK to put the verdict before your state change.

Read API docs Use the SDK
Buyer path

Approve one production boundary.

Review the security posture and request a keyed, metered API path for the action you are ready to gate.

Request API access Review security

Expansion path

Start narrow. Expand wide.

The API can gate any bounded software action. Start with one expensive boundary, then expand as teams trust the record.

01 · First boundary Start here

Pricing exceptions

Approve, deny, or escalate discount and packaging decisions before billing or CRM state changes.

  • Margin floors and guardrails stay explicit
  • record_hash and receipt_hash travel with the decision
  • Evidence explains why the call passed
Run the proof
02 · Second boundary After first boundary

Eligibility and routing gates

Refund, cancel, return, trial, access, and routing checks use the same verdict shape once one boundary is trusted.

  • Source-backed reference apps prove the pattern
  • Policy evidence stays attached
  • Stable remotes keep compatibility links alive
View reference assets
03 · Platform primitive Scale primitive

Execution gates

Agents, wallets, queues, and internal tools can require a Decide response before value moves or state changes.

  • Verdict gates the next action
  • Evidence travels into the audit record
  • Hash-linked records can prove what ran
Read platform guide

Proof resources

Run it. Integrate it. Review proof.

Go deeper only when the core idea is clear: one API call returns a record your system can store.

Run it Sandbox Make a decision and inspect the record.
Review proof Production evidence Inspect the flagship artifact and operating controls.
Live proof Security

Pricing for the Decision API

Simple model: run Evaluate for free validation, then buy a Production API tier by monthly decision records (10k -> 50k -> 200k) and live action boundaries. Annual billing saves 20%, and burst packs handle temporary spikes.

Evaluate (free)

Validate payloads before production purchase

Use docs and runtime references to test Rulebook v1 outputs and request-linked evidence fields.

Docs, reference API contracts, and sandbox payload testing
No production API key issuance
Docs-first integration validation path
Read API docs
Production API tiers

Pick by records and boundaries

Choose by monthly decision records, then by how many production action boundaries need to require a Decide verdict. Enterprise uses commercial contract terms when governance and procurement controls are strict.

First boundary
API Starter
From $299 / month

Up to 10,000 records/month

Self-serve production Decision API.

20 req/min default per API key
Decision Record, execution receipt, and outcome APIs
Self-serve production runtime
1 live action boundary
Start first boundary API details
Expansion tier
API Team
From $1,199 / month

Up to 50,000 records/month

Growth tier for multiple boundaries and faster launch support.

Higher throughput envelope than Starter
Up to 3 live action boundaries
Policy effectiveness, confidence, and anomaly review
Implementation support included
Request API Team quote API details
API Enterprise
From $3,999 / month

Up to 200,000 records/month

For multi-team governance, procurement review, and strict enterprise controls.

Custom throughput/uptime envelope
Procurement/security package
Audit-chain and benchmark controls
Custom boundary scope
Request Enterprise quote API details

Decision Intelligence grows with traffic

Read intelligence docs
Starter Capture the lifecycle

Decision Records, execution receipts, Outcome Records, and self-serve packet export for the first production boundary.

Team Run the feedback loop

Policy effectiveness, confidence, and explainable anomaly reports turn observed outcomes into rollout decisions.

Enterprise Govern proof at scale

Benchmarks, packet review, audit-chain governance, and the security package support procurement and multi-team rollout.

Plan terms snapshot

Compare decision scope, delivery model, rate-limit envelope, and expansion path before you request access. Default delivery is remote integration handoff (not on-site services).

Plan Price Delivery model Monthly decision scope Rate-limit envelope Overage / expansion Support + uptime terms
Evaluate ($0) $0 Sandbox + live demo validation only. No production usage. Shared demo limits; no contractual uptime terms. Move to API Starter, API Team, or API Enterprise for production. No production uptime terms.
API Starter (from $299/mo) From $299/mo Standalone keyed /api/decide access. Up to 10,000 decision records/month for one live boundary. Default Starter envelope: 20 req/min per API key (returned in x-ratelimit-*). Use burst packs (+10k/+25k/+50k) or upgrade to API Team. Self-serve runtime with docs-first implementation handoff.
API Team (from $1,199/mo) From $1,199/mo Quote-based API runtime with included implementation support. Up to 50,000 decision records/month across multiple boundaries. Higher commercial contract envelope than Starter. Use burst packs or move to Enterprise for stricter governance and larger envelopes. Launch support + contracted uptime terms + implementation support included.
API Enterprise (from $3,999/mo) From $3,999/mo Enterprise runtime with included rollout/governance support. Up to 200,000 decision records/month and/or strict multi-team controls. Custom throughput and uptime envelope by commercial contract. Further custom tiers above 200k/month as volume and controls expand. Full procurement/security package and enterprise support model with implementation support included.

Need first-boundary help? Request a pricing-exception workflow review.

FAQ

Can we start without a full platform rollout?

Yes. Choose API Starter for direct API runtime access, add burst packs for temporary spikes, or move to Team/Enterprise for larger envelopes and controls.

What happens right after payment?

You land on /payment/success with handoff steps, and receive kickoff confirmation by email. If missing after 10 minutes, check spam/promotions and contact support@decide.fyi.

Is Evaluate production-ready?

No. Evaluate is for runtime testing and payload validation only. Production usage starts with API Starter (or higher API tiers).

When does pricing move to custom scope?

Usually when monthly volume approaches or exceeds 200,000 decisions, when multi-team governance is required, or when procurement/compliance controls need custom contract terms.

Planning estimate: Model one product or internal workflow at a time, using your own decision-record volume, loaded review cost, and measured outcome deltas before treating any impact number as procurement evidence.

Workflow impact model

Use assumption-based decision-volume math before commercial commit so upside, spend, and cost assumptions stay explicit.

Workflow impact model

Estimate monthly review-time effect for one decision boundary and compare it against the selected kickoff or plan cost. This is a planning model, not a savings guarantee.

Reference scenario, not a promise: 5,000 records/month × 12 review minutes × 15% handle-time reduction × $25/hour ≈ $3,750/month modeled review-time impact before error-rate reduction.

Formula: hours saved = (records/month × avg review minutes ÷ 60) × reduction%; estimated monthly impact = hours saved × loaded hourly cost; net modeled impact = estimated impact - plan cost.

Hours saved / month 0 h
Estimated monthly impact $0
Plan cost in model $0
Net modeled impact $0

Cost comparison appears after input values are applied.

Modeled estimate only. Use your baseline, rollout records, and measured decision-outcome deltas before treating any impact number as procurement evidence.

Use Decide before software changes state.

Run the sandbox, copy an integration path, then request production access for one action boundary.

Run sandbox View integration guides Request API access

Console

Use Console as an evaluation and onboarding path: describe the workflow, map the first boundary, run proof, then request production access when the fit is clear.

Loading
Loading console status…

Evaluation Console

Describe your workflow

Docs-grounded

Tell us the software action you want to control. The mapper turns it into a first Decide boundary, relevant evidence fields, artifacts, and docs to review.

This is an evaluation aid, not production/legal/security advice. It only maps to documented Decide patterns.

Start with the action that changes state: CRM update, billing mutation, support refund, queue job, or agent tool call.

Production operations Readiness, rollout links, telemetry, and reports Open after the boundary is mapped and rollout access is available. Rollout access

Readiness Checks

Production-readiness checks confirm request delivery, checkout links, booking path, and confirmation channel before rollout.

Console access is linked to your signed-in Clerk account.

Next-step Actions

Use these when the evaluation is ready to become a first-boundary rollout.

API rollout payment API Starter monthly API Team monthly API Enterprise contact
  • Intake accepted: submission id and confirmation email are logged.
  • Checkout handoff: payment opens with prefilled email and linked reference id.
  • Readout cadence: weekly snapshot uses runtime metrics + export bundle.

Runtime Telemetry

Use your x-metrics-token to load 24h runtime metrics and export the rollout summary snapshot.

No metrics loaded yet.
Load metrics to calculate delivery health.
Access Intakes (24h)—
Access Delivery Success (24h)—
Access Delivery Failures (24h)—
Access Delivery Rate (24h)—
Decision API Signals (24h)—
MCP Signals (24h)—
Events (1h)—
Events (24h)—
Events (7d)—
Last Updated—
Top event (24h) Count
Load metrics to view top events.

Rollout Summary

Build a concise rollout brief from current readiness checks and telemetry. Use this for customer updates and weekly rollout readouts.

Generate report to produce a shareable rollout summary.
No report generated yet.
Reference applications · Stable remotes

Source-backed reference apps are a Decide proof surface.

Refund, cancel, return, and trial checks show how clients can consume deterministic verdicts with stable endpoints, source links, and replayable evidence.

Runtime docs Source alerts
Runtime docs MCP install URLs and REST API contracts Source alerts Confirmed source-page diffs from scheduled checks 100 vendor sources Refund, cancel, return, and trial
Proof surface

Reference apps prove the API shape.

Registry links, MCP install URLs, REST endpoints, and source references remain on *.decide.fyi. This is a preserved reference application for the broader Decision API.

Runtime docs Runtime status

Refund reference app

refund.decide.fyi
Source checks: scheduled every 6h
Live

Stable Decide runtime for refund eligibility checks. Direct declarative Rulebook v1 returns ALLOWED, DENIED, or UNKNOWN plus a signed rulebook result; no trusted adapter is required.

100 vendors Stateless Scheduled checks Free / No auth
Visit

Cancel reference app

cancel.decide.fyi
Source checks: scheduled every 6h
Live

Stable Decide runtime for cancellation penalty checks. Direct declarative Rulebook v1 returns FREE_CANCEL, PENALTY, or LOCKED plus a signed rulebook result; no trusted adapter is required.

100 vendors Stateless ETF detection Free / No auth
Visit

Return reference app

return.decide.fyi
Source checks: scheduled every 6h
Live

Stable Decide runtime for return eligibility checks. Direct declarative Rulebook v1 returns RETURNABLE, EXPIRED, or NON_RETURNABLE plus a signed rulebook result; no trusted adapter is required.

100 vendors Stateless Return method Free / No auth
Visit

Trial reference app

trial.decide.fyi
Source checks: scheduled every 6h
Live

Stable Decide runtime for trial terms checks. Direct declarative Rulebook v1 returns TRIAL_AVAILABLE or NO_TRIAL plus a signed rulebook result; no trusted adapter is required.

100 vendors Stateless Card & auto-convert Free / No auth
Visit

Stable demo + audit trail

Run the stable Decide reference remotes, inspect deterministic responses, and keep a scoped audit trail for QA and incident review.

Trust Suite: not run
Run Request
Run request to update output below.
Audit scope: this browser (guest). Sign in to scope trail and monitors to your account.
Response
Run a request to see output.
Audit Trail
Showing 0 of 0 runs.
Time (UTC) Reference app Mode Status Latency Req hash Actions
No runs yet. Run your first request.

Connect your agent

Add the stable Decide reference remotes to any MCP-compatible client.

Cursor VS Code Claude ChatGPT Codex Gemini
Claude Desktop / Cursor / Windsurf
{
  "mcpServers": {
    "refund-decide": {
      "url": "https://refund.decide.fyi/api/mcp"
    },
    "cancel-decide": {
      "url": "https://cancel.decide.fyi/api/mcp"
    },
    "return-decide": {
      "url": "https://return.decide.fyi/api/mcp"
    },
    "trial-decide": {
      "url": "https://trial.decide.fyi/api/mcp"
    }
  }
}
JSON-RPC — tools/call
curl -X POST https://refund.decide.fyi/api/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "refund_eligibility",
      "arguments": {
        "vendor": "adobe",
        "days_since_purchase": 12,
        "region": "US",
        "plan": "individual"
      }
    }
  }'
REST API
curl -X POST https://refund.decide.fyi/api/v1/refund/eligibility \
  -H "Content-Type: application/json" \
  -d '{"vendor":"spotify","days_since_purchase":5,"region":"US","plan":"individual"}'

Built for policy automations

Deterministic outputs, no hidden state, and stable remotes for products that build on Decide.

Deterministic

Same canonical input and rulebook version, same output. Fully auditable decisions your agent can cite.

Stateless

No sessions, no tokens, no stored data. Pure function over HTTP.

MCP Native

JSON-RPC 2.0 over HTTP POST. Works with Claude Desktop, Cursor, and any MCP client.

100 Vendors

Adobe, Netflix, Spotify, Microsoft 365, and 96 more. Checked every 6 hours via automated source checks.

Keyed Runtime

Reference validation runs sandbox-first; production Decision API access uses explicit keys and commercial runtime controls.

Open Source

Full reference rules, source links, and server code on GitHub. Verify everything.

Run rulebook-backed decisions with confidence.

Use the proof surfaces to validate the primitive, then integrate Rulebook v1 where your workflow needs deterministic verdicts.

Read runtime docs Decision API sandbox