The API page runs the call rather than describing it, through the proxy that already existed
Decided
/developers#playground makes a real POST to the pricing engine from the reader's browser, on page load and again on every change, and prints the HTTP status, the round-trip time and the unedited response body. It calls /api/cpq/calculate — this site's existing anonymous proxy — and says so in the panel, alongside the two-step authenticated cURL a reader's own client would use.
Affects: components/developers/api-runner.tsx (new), lib/sandbox-fixtures.ts (new), app/developers/page.tsx, scripts/check-api-reference.mjs, app/engineering/page.tsx
What the gap was. Every other block on that page was a *sample*: code to be copied, pasted and run somewhere else before the reader learns whether any of it is true. That is a fair ask of somebody who has already decided to integrate and far too much of somebody deciding whether the engine exists. The documentation was accurate; the interval between reading a claim and seeing it hold was the problem, and no amount of further accurate documentation shortens it.
Why no backend work was needed. app/api/cpq/calculate/route.ts has held one SALES credential for a dedicated sandbox tenant since the homepage calculator shipped. It exchanges that credential for a fifteen-minute bearer token, forwards a Zod-validated body with persist forced to false regardless of what the browser sent, caps the request at twelve line items, and returns the upstream body unchanged. A public page can therefore make a real call with no token in the bundle and no row written. The alternatives were both worse: exposing an authenticated endpoint to anonymous callers, or asking a visitor for a token before they have any reason to want one.
Why the proxy is named in the copy instead of glossed. "Live API" read next to a request that goes through a proxy is true and incomplete, and incomplete is how the failure this whole surface argues against begins. The panel states that the browser posts to this site, that the site holds the credential, that persist is forced false, and that the engine on the other side is the production one — then prints the direct call underneath so the difference is legible rather than inferred.
Why the catalogue codes get a guard. The runner's selects post SKU codes that must exist in the seeded tenant, or the first request on the page whose argument is "this is a real call" returns a 404 — worse than having no runner. The codes live in backend/prisma/seed-sandbox.ts, which a browser bundle cannot import, so lib/sandbox-fixtures.ts restates them and check:api-reference re-derives the seed's set and fails the build if the restatement names anything the seed does not create. The subset direction is deliberate: the seed may create SKUs the runner does not offer, never the reverse. This proves the two files agree; it does not prove the deployed tenant has been re-seeded, and nothing in that script opens a socket.
What would make this wrong. If the sandbox credential is ever given a role that can write, or if persist stops being forced server-side, the runner becomes a public write endpoint and must come down the same hour. If the proxy starts returning a synthesised body on upstream failure rather than a 503, the panel becomes a mock wearing a status code, which is precisely the thing it was built to disprove.
A note on the `/engineering` card. That page's closing card read "Run the API — call the pricing engine from this page" before any runner existed. It was softened to describe the OpenAPI document, and is restored here now that #playground answers. The sequence is left in a code comment on purpose: a page arguing for verifiable claims has to move its own copy in both directions.