Prism mock server from Sume's openapi.json: test without spending

To test a Sume client without spending credits, download the live spec from https://api.sume.com/reference/json, run prism mock -d openapi.json, and point your client's base URL at http://127.0.0.1:4010. Prism's README says the mock server listens on localhost:4010 by default, -d turns on dynamic response generation, and the CLI needs Node 18.20.1 or newer (read 2026-10-04).

A mock proves your request and response handling against the published shapes. It does not run a job, so it cannot prove a prompt works, that a webhook arrives, or that a job moves from queued to completed.

How do you run it?

Four commands. The spec is OpenAPI 3.0.3 and lists 171 paths at the time of reading, so the mock covers the whole public surface, not one product.

curl -s https://api.sume.com/reference/json -o openapi.json
npm install -g @stoplight/prism-cli
prism mock -d openapi.json
# in another terminal
curl -s http://127.0.0.1:4010/v1/jobs/job_123/status \
  -H "x-api-key: test" | head -c 400

What does a mock cover and what does it miss?

How should you wire it into tests?

• Make the base URL a setting. The SDK's baseUrl option and the CLI's API base URL setting both exist; note the CLI base includes /v1 and the SDK's does not.
• Run the mock in CI and assert on shapes (terminal is a boolean, next_poll_after_seconds is an integer or null), not on exact generated values.
• Re-download the spec on a schedule and diff it; a change in a required field is a breaking change you want to see before production.

Which responses should the mock return?

The error side is where a mock earns its keep, because real 402, 409 and 429 responses cost you either money or a flaky test. The public envelope has code, message, request_id and details, and the Formats surface adds retryable, retry_after_seconds and next_action. Write your client once against that envelope, then feed it a mocked 429 and a mocked 402 and check the two take different paths: back off and retry for the first, stop and alert for the second.

Keep one hand-written fixture next to the generated ones: a webhook body. The spec describes request and response routes, not the payload Sume posts to you, so copy a sample from Webhooks, sign it yourself with a test secret, and replay it at your receiver.

Where does the mock stop being enough?

For real state changes use a throwaway workspace on api.dev.sume.com, with a spend cap, and read Jobs and results for the polling contract your test double should replay. The API reference lists the routes the spec covers.