Databricks’ document APIs are GA—but the decision step and human review still matter

Databricks has made the synchronous REST APIs for document parsing, information extraction and classification generally available. The related ai_decide API, which chooses a next action such as routing a document or flagging it for review, remains in beta. That split is the practical release boundary: production applications can now obtain structured document data through supported endpoints, but teams should not treat the whole intake-to-decision chain as equally mature.

What moved to GA

The release exposes three building blocks to applications and agents. ai_parse_document converts document content, including tables and figures, into structured text and can calculate citation bounding boxes. ai_extract returns fields defined by a caller-supplied schema, with optional citations and confidence scores. ai_classify assigns labels using a business taxonomy and can also return rationales and confidence scores.

Databricks positions these synchronous calls for workflows that must react when a file arrives, rather than waiting for a batch pipeline. Its example contract flow parses an uploaded agreement, classifies the contract type, extracts terms into a review form, and writes the record to Delta only after a lawyer corrects or approves it. That is an important design signal: citations and confidence scores support verification; they do not replace it.

The deployment constraints

The extraction documentation adds constraints that the launch post only summarizes. A workspace needs serverless compute and Unity Catalog, along with access to a serverless usage policy with a nonzero budget. Availability is regional. Information-extraction agents use default storage for temporary transformations, checkpoints and internal metadata; Databricks says that associated data is removed when the agent is deleted.

The REST endpoint also has a default limit of 120 ai_extract requests per minute per workspace, with higher limits available through the account team. Extraction has a 128,000-token maximum context length and does not support union schema types. Those limits matter for inbox-scale systems: production architects need admission control, document sizing and a schema strategy before putting the endpoint behind an agent loop.

Why this matters for data agents

The release closes a common gap between unstructured intake and governed analytics. Extracted results can be consumed from an application, used by a custom Agent Bricks agent, queried through the ai_extract SQL function, or written on a schedule through a Lakeflow pipeline. Teams can therefore keep document-derived fields in the same governed data environment that downstream analytics agents query.

But the safe pattern is narrower than “give the agent the document.” Parse and extract into a declared schema, retain citations, evaluate fields against labeled ground truth, and put consequential routing or writes behind review—especially while the dedicated decision API is still beta. Databricks has shipped a production interface for document understanding; responsibility for validating what the workflow does with that understanding remains with the implementer.