Get Started
Key terms and concepts used across the Anesya API.
The credential used to authenticate requests to the Anesya API. It must be sent in the X-API-Key header. If the key is missing or invalid, the API returns 401 Unauthorized.
Parsing and extract are asynchronous workflows. Creating a parsing or an extract resource does not mean the final result is immediately ready. You must poll the resource until it reaches a final status such as FINISHED, PARTIAL_FINISHED, or ERROR. See API quickstart.
A stored source file inside Anesya. Documents are uploaded through /v0/documents and receive a stable UUID that can later be reused in parsing and extract calls. See Documents.
The UUID returned when a document is created. This is the canonical reusable reference for a stored file and is often the safest input format for downstream parsing and extract workflows.
The behavior of GET /v0/documents/{id}/download. The documented response is 302, which means the endpoint redirects the client to the underlying file location instead of returning the file metadata as JSON. See Documents.
A field present on parsing and extract resources that contains the failure message when processing ends in ERROR. Always inspect error alongside status when debugging a failed job.
The endpoint that turns a document or a completed parsing into structured JSON using one schema. Use extract when the goal is a final business payload rather than the raw document content. See Extract.
The markdown_content field returned by parsing. It contains a readable markdown version of the processed document and is useful for LLM workflows, manual inspection, and debugging extraction quality. See Parsing.
A free-form JSON object attached to documents and supported in parsing requests. Metadata is useful for keeping source-system information, customer references, or workflow context. Document search also matches metadata values. See Documents.
The parsing model selected for parsing and direct extract-from-document flows. The public API currently documents PIGALLE and PIGALLE_LITE. See Parsing.
The structured OCR payload returned by parsing in the ocr_content field. It complements markdown_content and can be used when you need page-level machine-readable parsing data instead of only the final markdown text. See Parsing.
The endpoint that converts a document into OCR output, markdown, optional picture descriptions, and page-level status information. It is the foundation for extract and the main entry point when you need visibility into the document itself. See Parsing.
A final parsing status meaning the parsing completed but one or more pages failed. This state is distinct from FINISHED and ERROR. It is often still usable if the failed pages are not critical. See API quickstart.
Optional image-description generation enabled with picture_description_enabled. It is useful when visual content matters to downstream workflows, but it should be enabled intentionally rather than by default. See Parsing.
The structure used by extract to decide what JSON to return. Every extract request requires one schema ID. The schema defines the target output shape and business meaning of the extracted result. See How to Build a JSON Extraction Schema.
The processing state of a parsing or extract resource. Common values include IN_QUEUE, IN_PROGRESS, FINISHED, and ERROR. Parsing also exposes PARTIAL_FINISHED. Status drives polling logic and workflow branching. See API quickstart.
An optional parsing feature enabled with table_verification_enabled. It should be used when table accuracy matters more than keeping the request as simple and fast as possible. See Parsing.
A multipart file sent directly to parsing or extract without first creating a stored document. This is useful for one-off workflows, while document upload is usually better for reusable files.
A public or pre-signed file URL passed directly to parsing or extract. Parsing also documents a URL-list input for fan-out workflows, while extract only documents single-document input. See Parsing.