> ## Documentation Index > Fetch the complete documentation index at: https://docs.parser-app.com/llms.txt > Use this file to discover all available pages before exploring further. # Readiness: database open, Luna and OCR configured > 200 when the job store answers and an OpenRouter key is configured, else 503 with which one is missing. In production it also needs the Mistral OCR key (scanned statements cannot be read without it); elsewhere `ocr_configured` only reports it. No key. ## OpenAPI ````yaml /openapi.json get /readyz openapi: 3.1.0 info: title: parser_backend summary: >- MCA packet parsing with GPT-6 Luna (OpenRouter), verified ledgers and underwriting metrics description: > MCA document parsing: merchant packets in (upload or email), verified bank-statement ledgers, ISO applications and underwriting metrics out. **How a packet is read** 1. *Intake* - files validated by content (PDF, PNG, JPEG), PDF safety-parsed, images converted to PDF; email attachments extracted from every MIME part. 2. *Split* - each PDF is split into documents (bank statement, merchant application, tax return, ...) by per-page classification and statement boundaries. 3. *Read* - a statement with a text layer is read by the **layout engine**: tables rebuilt from the text layer's geometry become the ledger JSON, with no model call. Pages without a text layer, and any statement whose layout read does not pass the gate, go to **Mistral OCR**, which returns each page as markdown with its tables inline; **GPT-6 Luna** reads that markdown as text into rows with a strict JSON schema: one owned page per call, the neighbouring pages' edges as context, fanned out in parallel. Every amount and balance Luna returns must be printed in its page's markdown. 4. *Gate* - a ledger is **verified** only when it reconciles to the cent (`opening + credits - debits = closing`), reproduces the bank's printed totals and keeps every running balance chain. If it still fails after the image read it is returned as `review_required`, never as data. 5. *Categorize* - a category and counterparty per row: revenue, MCA funding / payment, loan, NSF, overdraft, returned item, transfers, payroll, taxes, ... or unknown. Every ledger goes to GPT-6 Luna once as JSON (rows grouped by description, with counts, amounts and dates). Deterministic rules cross-check every row. 6. *Aggregate* - accounts and statement months (missing months flagged); MCA and loan positions decided by GPT-6 Luna over the packet's possible financing streams and checked against the rows (cadence cross-checks); monthly summaries, and the withhold, EBITDA and revenue math. 7. *Packet* - the files are one submission (`result.submission_packet`): its typed documents in order, which ones the decision rests on and why the others are excluded (duplicates, failed or unreconciled reads, unclassified documents, another business's statement), the merchant's details with their sources, month-by-month coverage, whether the statements are one unbroken history, the balance chain across statements, undisclosed accounts and cross-document fraud signals. Every Luna call is metered (prompt, cached, completion and reasoning tokens; provider-reported cost) and every answer is replay-cached: a re-sent document or window costs nothing. **Integrating** * *Authentication*: `Authorization: Bearer ` (or `X-API-Key`) on every `/v1` route. The credential is an API key (`pk_live_...`, created with `POST /v1/api-keys`, scoped to permissions) or a WorkOS AuthKit access token (a person, with the permissions of their role). Each belongs to one tenant; jobs, caches, webhooks and settings are tenant-scoped. Errors are `{"error": {"code", "message", "request_id"}}`. * *Test mode*: a `pk_test_...` key made with `mode: test` is a sandbox. Its jobs run with no Luna, Mistral OCR or transact (text-layer statements are still read by the layout engine), are marked `test_mode: true`, are not metered, and are listed and fetched by test keys only (a live key never sees them); their webhook events carry `livemode: false`. * *Submit*: `POST /v1/parse` (multipart) or `POST /v1/intake/email` (raw MIME). The answer is `202` with a `job_id` and `status_url`, or the finished job when `wait` seconds suffice. Send an `Idempotency-Key` to make a retry return the same job. * *Get the result*: register a webhook once (`POST /v1/webhooks`) and receive `job.completed`, `job.review_required` or `job.failed` when each job ends, signed with the endpoint's secret; then fetch `GET /v1/jobs/{job_id}`. Or poll that route (`?wait=` long-polls). Every job ends in one of those three states, and its event is stored with it: a job that runs past `JOB_TIMEOUT_SECONDS`, or that the service stopped during too many runs, fails with its `job.failed` event. * *Status*: `completed` - every check passed; `review_required` - the result is usable but `review_reasons` name what a person should look at; `failed` - nothing could be processed (`error`). version: 0.1.0 servers: - url: https://api.parser-app.com security: [] tags: - name: parse description: Submit documents for parsing - name: email description: Submit a raw email; its attachments are parsed as one packet - name: jobs description: Poll jobs and read results - name: underwriting description: Withhold, EBITDA and capacity calculator - name: webhooks description: Signed job events pushed to your endpoint, retried until delivered - name: usage description: Token usage, cost and service metrics - name: identity description: 'Who is calling: tenant, permissions, modules' - name: tenant description: This tenant's settings - name: api-keys description: 'Scoped API keys: create, rotate, revoke' - name: mailboxes description: Forwarding addresses and Gmail mailboxes, and each message's outcome - name: emails description: 'Every inbound email tracked: its thread, raw .eml, tags and erasure' - name: integrations description: Connections to the tenant's CRM and other systems, fed by job events - name: audit description: Every change made in the tenant - name: platform description: Tenants across the platform (platform:admin) - name: health description: Liveness and readiness paths: /readyz: get: tags: - health summary: 'Readiness: database open, Luna and OCR configured' description: >- 200 when the job store answers and an OpenRouter key is configured, else 503 with which one is missing. In production it also needs the Mistral OCR key (scanned statements cannot be read without it); elsewhere `ocr_configured` only reports it. No key. operationId: readyz_readyz_get responses: '200': description: Successful Response content: application/json: schema: {} ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.