← Analysis Auditor Token page

Analysis Auditor API

Everything the web app does, you can do from your own code: send an analysis, get back a structured audit with a verdict, a methodology review, a seven-pitfall scan, calculation spot-checks and the caveats that must travel with the numbers. Useful for gating a reporting pipeline, auditing a batch of dashboards, or refusing to publish anything that comes back “Needs revision”. Base URL https://api.skillsafe.ai/v1/app-api.

Input fields

The object you send. Only analysis is required.

FieldTypeMeaning
analysisstringThe analysis as written: prose, markdown/TSV/CSV tables, SQL and its results, methodology notes, the stated conclusion. Clipped at 60,000 characters — from the middle, keeping both ends, because an analysis states its recommendation last and that is the part most worth auditing.
contextstringOptional. The question the analysis answers, the audience, the decision that hangs on it, how the data was pulled. This materially changes the verdict: the same numbers can pass as a team update and fail as the basis for a budget decision.
numscanstringOptional. A summary of mechanical checks you ran yourself over the same text. Treated as a hint, not a fact — each item is verified against the analysis before it is repeated, and anything unconfirmable is dropped. The web app supplies its browser-side number scan here.
previousobjectOptional. Present only on a re-audit, carrying the earlier verdict, confidence, unresolved pitfalls and failed_checks. The audit then reports, issue by issue, whether the revision resolved it, left it open, or replaced it with something new.
retry_notestringOptional, and not for humans. Tells the model its previous reply did not parse and to re-emit the same audit in the required shape.

1. Get a token

Every call carries Authorization: Bearer <token>. Open the token page to sign in, reveal your token and copy a ready-made shell export. It never asks you to open the DevTools console. A guest token works for reading and estimating; a signed-in token is needed to run.

2. Check the session and balance

Confirms who the token belongs to and how many credits are available. Do this before a run: a 402 after submitting is avoidable.

GET/me

3. Estimate - free, no job created

Returns the credit hold a run would reserve, plus the resolved model and markup. It creates no job and charges nothing, so it is safe to call on every keystroke.

POST/estimate

4. Run and poll

Creates a job and returns when it is terminal. Always send an Idempotency-Key: a retried request with the same key returns the original job instead of billing twice.

POST/run

5. Run with streaming (SSE)

Same job, delivered as server-sent events. delta events carry incremental text, job carries the job id, and done carries the authoritative full output - trust done over the concatenated deltas, which can drop the tail.

POST/run-stream

Output contract

data.output.output is plain text in exactly this shape. This is what the app's parser decodes; a reply that breaks any rule below is discarded and retried once.

VERDICT: <Ready to share | Share with noted caveats | Needs revision>
CONFIDENCE: <integer 0-100>
SUMMARY: <2 to 4 sentences>

## Methodology
- <finding>

## Pitfall scan
- <Pitfall name> - <CLEAR|SUSPECT|FOUND>: <evidence>

## Calculation checks
- <PASS|FAIL>: <the check, with the actual numbers>

## Required caveats
- <caveat>

## Suggested improvements
- <suggestion>

## Open questions
- <question>
Parsing rules, as implemented. VERDICT: is the first line and must be exactly one of the three phrases. CONFIDENCE: is a bare integer 0-100. SUMMARY: may wrap and ends at the first blank line. All six ## headings must appear, spelled exactly, in that order. Every line inside a section is a - bullet, which may wrap onto indented continuation lines. An empty section carries the single bullet - None.

The verdict rule

A FOUND pitfall or a FAILed calculation check forbids “Ready to share”. There is no minor qualifier that gets around it. The renderer independently recomputes this from the parsed sections and flags the reply if the verdict line contradicts its own findings — worth reproducing in your own client rather than trusting the verdict string alone.

The seven pitfalls

Join explosion, survivorship bias, incomplete period comparison, denominator shifting, average of averages, timezone mismatch, selection bias. Each appears once in the pitfall scan marked CLEAR, SUSPECT or FOUND, with one line of evidence quoted from the analysis.

Grounding. The audit only checks what is on the page. A number whose derivation was not supplied becomes an open question rather than a silent pass, and a numscan flag that cannot be confirmed against the text is dropped rather than repeated.

The envelope and error codes

Every response is {"ok": true, "data": {...}} or {"ok": false, "error": {"code": "...", "message": "..."}}. Check ok before reading data.

StatusCodeWhat to do
400VALIDATION_ERRORThe input shape is wrong. error.details names the field.
401UNAUTHORIZEDMissing, malformed or expired token. Mint a new one from the token page.
402PAYMENT_REQUIREDThe balance is below the run's hold. Call /estimate first and compare against /me.
404NOT_FOUNDWrong slug or job id.
429RATE_LIMITEDBack off and retry with the same idempotency key.
5xxINTERNALRetry with the same idempotency key; a completed job is returned rather than re-billed.
Idempotency. Send Idempotency-Key on every /run and /run-stream. Derive it from a hash of the input plus an attempt counter, so a network retry collapses server-side while a genuine re-run gets its own key. The app does exactly this, including on its automatic reformat retry.