Pricing exception use case

Discount approval rules before a quote changes.

A discount approval API checks a proposed price against your policy before your application updates a quote. Decide returns yes, no, or review and a replayable Decision Record. Your CRM or billing application still owns the change.

See the approval matrix Read the Rulebook request Request API access

When an API fits the approval problem

Use this pattern when more than one caller can change pricing: a sales tool, a billing worker, or an AI sales assistant. Putting the policy check in the server-side change path gives those callers the same rules and leaves a record explaining each result.

Start with the exact action you need to control, such as applying a discount to one quote version. Identify where the price, cost basis, account permissions, and approval owner come from. A seller-entered margin or an agent's claim that a manager approved is not trusted evidence.

A decision layer, not a replacement for your sales stack

Decide does not send quotes, calculate your costs, or provide a CPQ system, CRM, reviewer inbox, or end-to-end approval workflow. If your existing quoting system already enforces the required policy and retains adequate evidence, another API may not be necessary.

A worked discount approval matrix

These thresholds are illustrative, not a recommended pricing policy: allow up to 15% discount when the margin is at least 15%; block any margin below 15%; route larger discounts to review. The margin check wins even when the requested discount is within its limit.

Expected outcomes for the sample Rulebook below
Discount / margin	Verdict	Your application's next step
10% / 22%	`yes`	Retain the record and check the exact quote version before applying the approved change.
15% / 15%	`yes`	Both thresholds are inclusive; continue through the same execution checks.
20% / 22%	`review`	Hold the change and send it to the pricing owner. Review is not approval.
10% / 12%	`no`	Block the change because the margin floor takes priority.
Missing or invalid facts	Hold	Validate and obtain the facts; do not coerce a blank margin or discount to zero.

Your policy may also need currency, contract value, term length, legal exceptions, tax, or account permissions. This two-input example does not approve those other conditions. Add their checks before using it for a real quote.

Send trusted facts and a versioned Rulebook

Send this JSON body to POST https://www.decide.fyi/api/decide from your server with Content-Type: application/json, your x-api-key, and an x-idempotency-key scoped to the quote version and proposed change. Keep credentials out of browser code. This page does not make an API call.

JSON request · illustrative discount policy

{
  "mode": "rulebook",
  "binding_mode": "direct_declarative_rulebook",
  "rulebook": {
    "schema_version": "rulebook_v1",
    "rulebook_id": "discount_approval_example",
    "version": "2026-09-19",
    "input_schema": {
      "required": ["discount_percent", "margin_percent"],
      "properties": {
        "discount_percent": {"type": "number"},
        "margin_percent": {"type": "number"}
      }
    },
    "rules": [
      {
        "rule_id": "block_low_margin",
        "priority": 200,
        "condition": {"field": "margin_percent", "operator": "lt", "value": 15},
        "outcome": {
          "decision": "no", "verdict": "BLOCK_DISCOUNT",
          "action": "block_discount", "reason_code": "MARGIN_FLOOR_BREACH"
        }
      },
      {
        "rule_id": "allow_standard_discount",
        "priority": 100,
        "condition": {
          "all": [
            {"field": "discount_percent", "operator": "lte", "value": 15},
            {"field": "margin_percent", "operator": "gte", "value": 15}
          ]
        },
        "outcome": {
          "decision": "yes", "verdict": "APPROVE_DISCOUNT",
          "action": "apply_discount", "reason_code": "STANDARD_EXCEPTION_ALLOWED"
        }
      }
    ],
    "default_outcome": {
      "decision": "review", "verdict": "REVIEW_DISCOUNT",
      "action": "route_to_pricing_owner", "reason_code": "PRICING_OWNER_REVIEW_REQUIRED"
    }
  },
  "context": {
    "workflow": "pricing_exception",
    "source_record_id": "quote_1042_revision_3",
    "requested_action": "approve_discount",
    "target_system": "crm",
    "target_object_id": "quote_1042",
    "mutation": "quote.discount.update",
    "inputs": {"discount_percent": 10, "margin_percent": 22}
  }
}

Validate both percentages as finite numbers in your permitted range before calling the API. For this example, use 0–100 and reject blank or missing values. Derive margin from the trusted cost and final proposed price; a pre-discount margin would answer the wrong question. Store the quote revision and proposed values with the request.

Make approval part of the write path

01 · Read

Capture the proposed change

Read the current quote, permissions, cost basis, and policy on the server. Bind the request to the exact quote version.

02 · Decide

Evaluate and retain the result

Keep the complete Decision Record with the quote: verdict, matched rule, reason, policy version, hashes, and action binding.

03 · Enforce

Only an approved change proceeds

Validate the returned record and action binding. A timeout, error, invalid response, no, or review must not reach the write path.

04 · Reconcile

Record what actually changed

Use a version-checked write so a concurrent quote edit cannot reuse an old approval. Attach the execution receipt or failure to the decision.

A human review should return through your controlled approval process, not become a client-side override. If the price, margin, terms, policy, or quote version changes, evaluate the updated proposal. Idempotency prevents duplicate processing of the same request; it does not make an outdated verdict safe.

Authentication, response views and idempotency Validate Decision Records CRM write-back integration JavaScript SDK

Prove one approval boundary before expanding

Test a standard quote, an exact-threshold quote, a low-margin quote, an exception, missing facts, an API timeout, and a quote edited between decision and write. Check both the verdict and whether the write was actually blocked. Then choose an approval owner and define how that owner resolves review cases.

Measure review volume, time waiting for an owner, blocked writes, and exceptions that needed another policy rule. These are implementation checks, not a promise of higher sales or fewer errors. An approval record only helps if every relevant writer respects it.

Request API access Start with the quickstart Gating an AI sales agent?