create_order
Assemble a basket and get exact prices plus Stripe checkout links. Checkout runs on Stripe's hosted page, completed by whoever holds the payment credentials. Pass dryRun:true to REHEARSE: same validation, same price math, clearly labeled, no order recorded, no links issued, nothing billed — integration-test the full flow risk-free. Item ids — plans: 'pilot', 'desk-private', and 'api' (the Metered API account: your identified key — self-issue one FREE at POST /api/keys, no human in the loop — with billing activated by the desk on this order, usage billed monthly at tariff rates, nothing preset — get_quote prices your exact basket first, get_account shows the live statement); unit: 'watch' (reads of the watched question included); and 'balance' — a BALANCE on your own key, funded once with an amount in USD (min $5, max $500) and drawn down at the flat published Read rate as you ask. Reads are metered per use at the flat tariff rate and are never sold as PREPAID PACKS — a pack is a discounted bundle sized to your guess about how much you will use, and we do not sell one. A BALANCE is a different thing and is sold: the same meter funded in advance, at LIST, no discount, no expiry, no minimum draw, unused balance refundable in full on request. It exists so your principal fills a card form ONCE, ever, instead of once per purchase. Live UNIT prices come from /api/tariff and this description states none of them — the balance band above is a limit on what you may FUND, not a price. Watch topics are SELF-SERVE end to end: pass topics and every topic something we keep reads comes back with a checkout link at the published Watch rate — including one nobody watches yet, whose price the desk mints on demand with no human in the loop (that one needs your identified key, free and self-issued in one call at POST /api/keys, and arrives in minutes; poll get_order or the statusUrl on the line). Each quoted topic carries its coverage state from the same check get_quote runs, and coverage decides the sale: a topic nothing we keep reads yet, or one the check could not confirm, comes back status: "not-covered" at $0 with no checkout link and is never minted, beside the free propose_topic call that asks us to start keeping it. We never bill for coverage we cannot fill. The api line still records intent and the desk activates the account. Every line states its own state and what to do next. A live (non-dryRun) order returns handoff: a ready-to-forward note for whoever holds the payment credentials — what is being bought, the price, the money-back terms, the payment link(s), and how you can poll get_order until it is paid.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| No | Contact email to attach to the order intent (optional) | ||
| items | Yes | Array of {id, quantity?, amount?} — catalog ids above; `quantity` applies to unit items only, and `amount` (USD, min 5 / max 500) applies to the 'balance' item only and is required on it | |
| dryRun | No | true → rehearse: validate + price the basket, record nothing, issue no links, bill nothing | |
| topics | No | Optional: the topic names this order's Watch lines cover. Pass each topic's `name` from get_quote verbatim, so this order checks the same topic the quote priced and you see the same verdict; your own words are checked as written and can read differently. Topic numbers are not accepted: a digit-only entry is refused with an explanation, never guessed at. Carried verbatim onto the recorded intent so scoped concerns survive the quote→order handoff. Max 12, each ≤200 chars. | |
| quoteId | No | Optional: the quoteId from get_quote — recorded on the order intent so the desk provisions against that exact quote. | |
| idempotencyKey | No | Optional client key (≤128 chars): makes the orderId deterministic and a retried call return the original intent instead of recording a second one — safe machine retries |