Extract structured data from a document
extract_dataExtract specific structured values (totals, line items, dates, names, tables) from a document (extract group) using a saved extractor, an inline JSON Schema, or schema-less inference. If the user says "OCR" but wants specific values out, use this tool; for the raw text/markdown of the pages use parse_document instead. Provide exactly one of extractor or config, or omit both for schema-less inference (guided by config.extractionRules when config has no schema; not usable with package). If a saved extractor turns out not to exist, rerun THIS tool without the extractor (schema-less) — do not fall back to parse_document for value extraction. For one merged result across 2-50 related documents, pass package instead of file. detail: "full" returns per-field source citations and confidence — the only way to prove where a value came from (provenance); parsing cannot cite. Async: a status: "running" result with a runId is not an error — resume with get_extract_run passing that runId, the same workspaceId and environment, and wait: true, repeating until the status is terminal; never re-submit the document. On UNAUTHORIZED or NOT_FOUND, re-call get_me for the granted targets. Output shape (output.value, per-field metadata, confidence, citations) is documented at https://docs.extend.ai/extraction/response-format.md (get_documentation).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | The document to extract from. Mutually exclusive with package. Exactly one of id/url/text — e.g. { "url": "https://..." } or { "id": "file_..." }, never a bare string. | |
| config | No | Inline extraction config: { schema?, extractionRules?, baseProcessor?, advancedOptions?, parseConfig? }. Writing schema by hand? ALWAYS call get_documentation with https://docs.extend.ai/extraction/schema.md FIRST and follow the returned dialect — the rules below are only a summary (field-naming best practices: https://docs.extend.ai/extraction/best-practices/field-names-and-prompt-crafting.md). schema is a JSON Schema: root "type": "object"; primitives nullable via a type array (["string","null"]); objects/arrays keep a plain "type" (never a nullable array) and objects always need "properties"; max depth 5; enums include null; no anyOf/oneOf/allOf/patterns. Date/currency/signature fields add "extend:type" alongside a normal type. A currency field is exactly: { "type": "object", "extend:type": "currency", "properties": { "amount": { "type": ["number", "null"] }, "iso_4217_currency_code": { "type": ["string", "null"] } } } — never a bare number. Omit schema for schema-less mode (no docs needed): extractionRules then doubles as schema-generation instructions. | |
| detail | No | "concise" (default): status, output, failure fields, dashboardUrl. "full": adds config, confidence/citations, usage, timestamps. | |
| package | No | Multi-document corpus (2-50 files, id/url only) extracted into one merged result. Mutually exclusive with file; not usable with schema-less mode. | |
| metadata | No | Arbitrary key-value metadata stored on the run. | |
| priority | No | Queue priority (1-100). | |
| extractor | No | Saved extractor to run. Mutually exclusive with config; omit both for schema-less inference. | |
| environment | Yes | "TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment). | |
| waitSeconds | No | Max seconds to block waiting on the run (clamped to the server wait budget). | |
| workspaceId | Yes | Target workspace (ws_...). Must be a granted workspace — get_me lists the accepted values. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| files | No | ||
| runId | Yes | ||
| output | No | Extracted values (PROCESSED only). | |
| status | Yes | Terminal status, or "running" (resume via the get tool). | |
| runType | No | ||
| dashboardUrl | No | ||
| failureReason | No | ||
| failureMessage | No |