Discount approval rules before a quote changes.

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 worked discount approval matrix

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

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.

Run a quote check with your agent

This runnable recipe uses the released paid decide_prepaid_evaluate tool. No separate quote plugin or specialist purchase is needed. $10 buys 1,000 completed records; yes, no and review each count as one record. Reads and identical retries add no record debit but consume service requests. It does not apply a discount, buy credit or raise a limit.

1. Connect Decide Runtime, create your account, and explicitly fund and approve its bounded allowance.
2. Download the dependency-free quote workflow builder. Supply your approved policy and a fresh trusted quote, including its cost, currency and exact revision. Money uses integer minor units; percentages use basis points. Missing cost or authority means stop, not guess.
3. Build one request locally with node quote-runtime-workflow.mjs build quote.json > operation.json. This is free and makes no network call. Preserve that exact output for every retry and read; rebuilding changes its timestamp.
4. Give the prepared operation.json to your connected agent using the prompt below. The policy supplied by you is not independently verified business approval.
5. Before any separately authorized CRM write, your application must recheck the quote/policy hashes, revision and validity deadline. A saved yes is not execution authority.

Use Decide Runtime to check this discount against the supplied approved policy and trusted quote. Call decide_prepaid_evaluate once with the exact attached operation JSON. Report the verdict, reason, policy version and operation ID. Do not apply the discount, approve an exception, invent facts, buy credit or increase limits. Stop on no, review, pending or refusal. If the result is uncertain, preserve the original request for decide_prepaid_get_record; never create a new ID to clear a hold.

{
  "policy_approved": true,
  "policy": {
    "policy_id": "your-approved-sales-policy", "version": "v1", "currency": "USD",
    "max_discount_bps": 1500, "max_discount_minor": 20000, "min_margin_bps": 2000,
    "valid_from_ms": 0, "valid_until_ms": 0,
    "max_fact_age_ms": 600000, "decision_ttl_ms": 600000
  },
  "quote": {
    "quote_id": "your-quote", "revision": "v1", "policy_id": "your-approved-sales-policy",
    "currency": "USD", "list_amount_minor": 100000, "cost_minor": 60000,
    "captured_at_ms": 0, "status": "draft"
  },
  "proposal": { "quote_id": "your-quote", "quote_revision": "v1", "discount_bps": 1000, "request_id": "your-stable-request-id" }
}

Advanced: the on-request API integration

The following older API example is a separate on-request integration, not the prepaid MCP connection above. Use the runnable Runtime recipe for self-serve access.

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.

{
  "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": 20},
        "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": 20}
          ]
        },
        "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

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.

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.