The console

The core does the reading. This console is what you operate around it: who you are, what the core says about your projects, and a place to try one.

Everything on this page is a section of the console you can open.

Identity and access#

You sign in with GitHub. That is the whole of what this console stores about you: a user and a session. Your projects are yours: the core hears your own id on every call, so nobody else sees them, and there is no organisation to join and no role to hold.

One column is set outside the app: is_admin, 1 or 0, changed by an operator in SQL and shown next to your name. It opens the admin pages: the accounts this console holds, and the model catalog a project's tier resolves to. Nothing in the console can set the flag.

Projects#

A project lives in the core, not here. It holds one JSON Schema, one key, one delivery choice and its history, and the core scopes every read to the identity this console proves: yours.

The console creates one in a single call: name, model tier and schema go out together, and the core answers with the project, schema version 1 and its first key. That is why the console has no project table: a second list would only be a list that can go stale.

The key#

A project is called with Authorization: Bearer s2j_… and nothing else. No timestamp, no signature. The key is answered exactly once, when the project is created or the key is rotated, and this console keeps no copy of it.

Rotate it and the previous secret stops working immediately. The budget belongs to the project (config.rate_limit_rpm), not to the key, so a rotation never resets it.

Schema versions#

One project, one document, many versions. Saving appends a version and moves the project to it; a snap already answered keeps the version it ran against, which is why the console shows the history rather than only the current document.

The document is the whole instruction: the core derives the prompt from it and validates the answer against it, so there is no second prompt to keep in sync.

Delivery#

Two ways for a finished snap to reach you, chosen per project:

• Polling (the default) at the interval you set;
• Webhook: the core posts the same four fields, signed with the key you supplied (X-Timestamp and X-Signature over the four-line canonical), and the key is sealed at rest on the core's side.

The probe is the handshake: the core posts a signed event and refuses anything but a 2xx, so you find out the endpoint is real before a snap depends on it.

History#

Every snap is kept as a state, not as a payload: ref, status, error code and message, and the timestamps. Four words, in order: REGISTERED, EXECUTING, COMPLETED, FAILED. One one page of them is enough to tell a bad scan from a bad schema.

The extraction itself comes back on the partner route, with your key, so the console never holds a customer's data.

Usage#

Snaps, completions, failures and tokens over a window, per project and across all of yours. The core aggregates; the console only picks the window. The number you see is the number the core billed, because it is the same query.

Workbench#

Every project has one, on its own page: a playground, not a separate screen. Paste the project's key, drop an image, and the console makes the same call your integration will: POST /partner/v1/snaps with Authorization: Bearer …. It then polls the status until it is terminal and shows the extraction, the verdict and any violations.

The key is the point: the console stores none, so you paste it, it lives in that browser tab, and a reload forgets it. Nothing about the image is kept here, and the core keeps only its hash and the result.

Support#

Every call carries a trace id, from the browser through the console to the core. That id is the fastest thing to send us: it names the request without describing your document.

Where to go next#

• The contract itself is on the API reference.
• What a read costs, and how a tier changes it, is under Pricing.