Document AI Overview
Sarvam’s Document AI API provides enterprise-grade document processing powered by Sarvam Vision 1.5, our state-of-the-art multimodal model.
Turn any document into structured, searchable, machine-readable data — whether you need the full page digitized or specific fields extracted.
Two ways to process a document
Document AI gives you two endpoints over the same job lifecycle. Pick based on what you need out the other end.
Full-document OCR. Extracts all text, preserves layout and reading order, and parses tables into HTML or Markdown. Use when you want the whole document as clean, structured content.
Schema-based key-value extraction. You define the fields you want; Sarvam Vision 1.5 returns them as structured JSON. Use when you want specific fields, not the whole page.
What’s new
Document AI supersedes the earlier Document Digitization API. Two changes matter most: (1) processing is now powered by an upgraded Sarvam Vision 1.5, trained to do both OCR and key-value extraction; and (2) alongside full-document Digitise (OCR), we now offer Extract for schema-based field extraction. The API namespace is doc_ai and jobs are created with a single digitise() / extract() call.
Key Features
Native support for all Constitutionally recognized Indian languages and English with script-native accuracy.
Full-document digitization and targeted key-value extraction from one API and one job model.
Intelligent table detection and conversion to structured HTML or Markdown.
Define exactly the fields you want in Extract, returned as structured data.
Intelligent reading-order detection and complex layout handling.
Scalable API with job management, progress tracking, and error handling.
Supported Languages
Document AI supports all 22 Constitutionally recognized Indian languages plus English:
Supported Input Formats
Page Limit: Both PDF and ZIP uploads are limited to a maximum of 10 pages. Exceeding this limit returns a 400 Bad Request with code invalid_request_error. Split larger documents into batches of 10 pages or fewer before uploading.
For ZIP files, include only JPG and PNG document pages in a flat structure (no nested folders). The API processes all pages in the archive and maintains page order based on filename.
Output Formats
Digitise
The output_format parameter controls the primary content format. Choose html (the default) or md (Markdown).
JSON page-level data is always included by default. Whether you choose HTML or Markdown, a JSON file with structured page-level data is always included alongside it, so there is no json option here — passing one returns 400 OUTPUT_FORMAT_INVALID. (Extract does accept json; see below.)
The download is a ZIP archive holding the primary file, a metadata/page_NNN.json per page, and a manifest.json.
Extract
Quick Start — Digitise
API parameter names: Document AI uses language and output_format values "md", "html", or "json". Do not use language_code (ignored) or "markdown" (returns 400 — use "md"). This differs from STT, translate, and LID endpoints.
Quick Start — Extract
Extract takes the same document input, plus a schema describing the fields you want (or a saved config_id). The result is structured JSON with the field values you defined.
Provide exactly one of schema or config_id. Use an inline schema for ad-hoc extraction, or a saved config_id for a schema you’ve set up on the platform. Sending both, or neither, returns a 400.
Pass schema as a JSON string, not an object. It’s sent as a multipart form field, so both SDKs type it as a string — use json.dumps(schema) in Python and JSON.stringify(schema) in JavaScript. Passing a dict in Python raises AttributeError: 'dict' object has no attribute 'read'.
Note also that the JavaScript SDK is generated without a serialization layer, so its request parameters and response fields use the wire names (output_format, job_id, pages_processed), not camelCase. file takes an array, and job_id is a positional argument — getStatus(job_id), not getStatus({ job_id }).
Schema rules
The inline schema is a JSON object with these constraints:
- Root must be
type: "object"with a non-emptypropertiesmap. - Every field needs a
typeand a non-emptydescription— the description guides the model, so make it specific. - Supported field types:
string,number,integer,boolean,object,array. - An optional
enummay be supplied to constrain values. - Maximum nesting depth is 4.
Job Lifecycle
Both digitise() and extract() create and submit a job in a single call, returning a job_id and an initial status. You then poll get_status() until the job reaches a terminal state, and fetch output with get_results() (structured data) or get_download_url() (output file).
Job States
Terminal states are completed, partially_completed, failed, and rejected.
Status Response
Error Handling
Error Handling Example
Error Codes
The full error-code table, retry guidance, and SDK exception reference live on the central Errors & Troubleshooting page. Errors specific to this API:
Best Practices
Reach for Digitise when you want the whole document; reach for Extract when you want specific fields. Don’t post-process a full digitise just to pull three fields — define a schema and let Extract do it.
In Extract, each field’s description guides the model. “Insurance policy number, top-right, format ABC-1234” outperforms “policy number”.
Always specify the correct language code for optimal accuracy, especially for Indian-language documents.
Monitor usage in the status response to track progress, and handle partially_completed jobs gracefully.