Skip to main content

Introduction

The extractions.create method in Retab’s document processing pipeline uses AI models to extract structured data from any document based on a provided JSON schema. This endpoint is ideal for automating data extraction tasks, such as pulling key information from invoices, forms, receipts, images, or scanned documents, for use in workflows like data entry automation, analytics, or integration with databases and applications. The typical extraction workflow follows these steps:
  1. Schema Definition: Define a JSON schema that describes the structure of the data you want to extract.
  2. Extraction: Call client.extractions.create(...) to process the document and retrieve structured data.
  3. Validation & Usage: Validate the extracted data (optionally using likelihood scores) and integrate it into your application.
The SDKs already help here:
  • Python parses message.parsed against the JSON schema you pass in
  • Node accepts a JSON schema object, a schema file path, or a zod schema directly
You can still add your own application-level validation if you want stricter business rules. Unlike the parse method that focuses on raw text extraction, extract provides:
  • Structured Output: Data extracted directly into JSON format matching your schema.
  • AI-Powered Inference: Handles complex layouts, handwritten text, and contextual understanding.
  • Modality Support: Works with text, images, or native document formats.
  • Consensus Mode: Optional multi-run consensus for higher accuracy on ambiguous documents.
  • Likelihood Scores: Provides likelihood scores for each extracted field.
  • Batch Processing Ready: Efficient for high-volume extraction tasks.

Extract API

ExtractionRequest
ExtractionRequest
Returns
Extraction
An Extraction record with the extracted data, usage details, consensus likelihoods, and a persisted id.

Build Your Schema

Retab extraction quality depends heavily on schema quality. The fastest way to improve a schema is to run extraction with consensus enabled, inspect unstable fields, and tighten the schema until the low-confidence areas disappear.

Why consensus helps

Consensus is Retab’s practical schema debugging loop. Multiple extraction runs using the same schema reveal where the model disagrees. Those disagreements usually mean one of three things:
  • The field name is ambiguous
  • The field description is too loose
  • The field type or structure is asking the model to normalize too much at once
As a rule of thumb, fields below 0.75 likelihood need attention before production use.

Schema improvement levers

Example: iterating on a schema

Example interpretation:
  • name: 1.0 means the field is stable
  • date: 0.5 usually means the format is underspecified
  • address: 0.25 usually means the field should be decomposed into structured subfields
Common next step:
  • change date to an ISO date field
  • split address into street, city, zip_code, and country
Best practices:
  • Start schema iteration with n_consensus=4 or 5
  • Fix the lowest-likelihood fields first
  • Test with diverse documents, not one golden sample
  • Treat consensus as a schema debugging tool, not just a scoring feature

Reasoning

Use reasoning when a field requires calculation, conversion, or multi-step logic. Retab supports this through the X-ReasoningPrompt JSON Schema annotation. The model then produces an auxiliary reasoning___<field_name> output during extraction, which gives it room to work through the logic before returning the final field value.

Example: Celsius to Fahrenheit

Without reasoning, a model may copy 22.5 directly. With reasoning enabled, it is more likely to compute 72.5 and explain the conversion in reasoning___temperature. Use reasoning for:
  • unit conversions
  • tax or total calculations
  • date normalization
  • derived fields that depend on multiple source values

Sources

Retab can also return provenance for extraction results. Given an extraction ID, sources returns the same output structure, but every scalar leaf becomes a { value, source } object pointing back to the original document location. This is useful for:
  • review UIs with citations
  • provenance audits
  • highlighting extracted fields in viewers
  • debugging incorrect outputs

Response shape

Every sourced leaf looks like this:
Common anchor types:
  • pdf_bbox: normalized bounding box on a PDF page
  • image_bbox: normalized bounding box on an image
  • csv_cell: row and column reference in CSV
  • spreadsheet_cell: sheet and cell reference in XLSX
  • docx_text_span or docx_table_cell: DOCX paragraph or table-cell location
  • text_span: line and character offsets in plain text
If a field cannot be sourced, Retab still returns the value and sets source to null.

Managing Saved Extractions

Extractions are persisted resources. After calling client.extractions.create(...), you can retrieve them later, list them with pagination, and filter them by metadata or date range.

Listing extractions

Use client.extractions.list(...) when you need to browse recent extractions, paginate through large histories, or filter by metadata.
Useful list filters:
  • limit: page size
  • order: asc or desc by creation date
  • before and after: id pagination
  • from_date and to_date: date-range filters
  • metadata: exact-match metadata filtering

Getting an extraction by ID

Filtering by metadata

Metadata is useful when you want to organize extractions by tenant, workflow, batch, or any other business key you attached at creation time.
For full request and response details, see the extraction endpoints in the API Reference.

Use Case: Extracting Event Information from Documents

Extract structured calendar event data from a booking confirmation image and validate likelihood scores before saving to a database.

Use Case: Passing Extra Instructions

Use instructions to provide a freeform note that guides the extraction — useful for iteration context from a loop, tenant-specific conventions, or any hint that isn’t captured by the schema itself.

Metadata Filters

Use metadata at extraction time to tag each document with stable identifiers, then filter those extractions later using the same keys. This is especially important in multi-tenant systems: always include stable tenant-scoping metadata keys to avoid cross-tenant contamination.

1. Tag the extraction request with metadata

2. Filter extractions by metadata

When multiple metadata keys are provided, all keys are applied together as exact-match filters.

Best Practices

Model Selection

  • retab-large: Use for complex documents requiring deep contextual understanding.
  • retab-small: Balanced for accuracy and cost, recommended for most extraction tasks.
  • retab-micro: Faster and cheaper for simple extractions or high-volume processing.

Schema Design

  • Keep schemas concise: Only include required fields to improve extraction accuracy.
  • Use descriptive description fields: Helps the AI model understand what to extract.
  • Add X-SystemPrompt for custom guidance: E.g., “Focus on freight details” for domain-specific extractions.

Confidence Handling

  • Set a threshold (e.g., 0.7) for automated processing.
  • For critical tasks, enable n_consensus > 1 to average results and boost reliability.

Using Instructions

  • Use instructions to pass domain-specific hints that aren’t part of the schema.
  • Ideal for: currency defaults, date format preferences, handling ambiguous abbreviations, or specifying regional conventions.
  • Keep the string concise to avoid diluting the extraction focus.