The Five-Minute Quickstart, Annotated

The quickstart is one curl command. The reason it repays five minutes of reading is what comes back: not just outputs, but the audit surface around them.

There are no API keys and no signup. The first call is the integration: POST JSON inputs to a model's endpoint, get JSON back. This piece annotates that round trip line by line, because the response contains more than the answer — it contains the spec version, the sentinel annotations, and the SHA-256 record that make the answer citable later, and an integration that ignores them is leaving the best part of the product on the table.

The request

curl -s https://worthune.com/api/v1/models/relocation -X POST -H 'content-type: application/json' -d '{"currentSalary": 95000, "newSalary": 108000, "currentMonthlyExpenses": 4200, "newMonthlyExpenses": 4900, "movingCosts": 6000, "currentSavings": 40000, ...}'

Anatomy of the response

The response opens with ok: true and the model name, then the two fields that anchor everything else: specVersion, the exact behavior version that produced this answer, and specUrl, the human-readable contract that version points to. Then your inputs, echoed exactly as received — the least glamorous field and the one that makes the answer reproducible, because a stored answer without its inputs is a rumor.

The outputs object carries the computed results, chart arrays included — series are part of the verified contract, not a UI garnish. Beside it, three fields do the trust work. The sentinels array annotates any documented sentinel value in this response, with a triggered flag — so when a refinance never breaks even, the response does not just say Infinity, it tells you the field, the meaning, and that it fired. The assumptions array names the spec version the answer implements plus the contract’s constraint notes — cross-field rules, unit conventions, and scope caveats. The facts array lists any facts-registry constants the model consumed — id, label, value, applicable period, and source name — and is honestly empty for models that use none.

Last comes the record: a SHA-256 hash over exactly four fields — model, specVersion, inputs, outputs — in canonical key-sorted JSON, with the field list and the hashing recipe included in the response so any party can recompute it independently.

• ✓Store the record.sha256 — it is the proof of what the answer was.
• ✓Store the inputs, outputs, and specVersion — together with the model name they are what make the hash recomputable.
• ✓Render the sentinels array — a triggered sentinel changes what the UI should say.
• ✓Link the specUrl near the answer — that is the glass-box link.
• ✓Treat the facts array as citations — each row names its source.

The error you should trigger on purpose

Before shipping, send one bad request deliberately. Ask the fire model for a currentAge of 150 and the response is ok: false with a structured error: the field name and the message that it must be between 18 and 65. Omit fields and each missing one is named. Nothing is clamped, nothing is guessed — a request outside the published domain is rejected with enough structure to render a helpful form error. That behavior is the API's whole validation philosophy in one probe, and your error-handling code can be written against it in minutes.

Verifying the record, once

The record is only worth storing if you have verified you can check it, so do it once during integration: take the response, extract the four fields the record names, serialize them in canonical key-sorted JSON, hash with SHA-256, and compare. The SDKs ship a one-call helper for this, and the recipe is deliberately simple enough to implement in any language in a few lines — byte-exact canonical JSON is the only subtlety, and the response documents the convention. After that one verification, storing the envelope is cheap insurance: any stored answer can be proven, later, to be exactly what the API returned.

What the quickstart deliberately does not include

No authentication section, because there is none to configure — fair use is a written guideline (five thousand runs a month per app), not a metered key, and the only hard limit is an abuse backstop far above human traffic. No SDK-installation prerequisite, because the SDKs are conveniences over plain JSON, not gatekeepers. And no sandbox-versus-production split: there is one API, the one users get, with behavior pinned by spec version rather than by environment. The absence of ceremony is the onboarding: the first call a developer makes is a production call that returns a verifiable answer.