Migrating to API Version 2026-02-09
Migrating to API Version 2026-02-09
Migrating to API Version 2026-02-09
The 2026-02-09 API version is a significant improvement designed to make your integration cleaner, more type-safe, and easier to maintain. We’ve listened to developer feedback and restructured the API around clearer resource types and better SDK support.
Here’s what you’ll get with the new API version:
The unified /processors and /processor_runs endpoints have been split into dedicated endpoints for each resource type:
This means fully typed SDK responses—no more checking type fields or casting outputs:
TypeScript bonus: Define schemas with Zod for fully typed output values:
Previously, you had to create and manage an extractor, classifier, or splitter resource before running. Now you can pass your config inline—perfect for managing schemas entirely in code.
New synchronous endpoints let you process a file and get the result in a single request—no polling or webhooks needed. These are ideal for onboarding, testing, and low-volume use cases:
The async *_runs endpoints are the recommended approach for production. The SDK provides createAndPoll / create_and_poll methods that handle polling with exponential backoff:
Available for all run types: extractRuns, classifyRuns, splitRuns, parseRuns, editRuns, workflowRuns.
Workflow runs can take a long time. Complex workflows may run for hours. For workflows, consider using webhooks instead of polling unless you know the workflow will complete quickly.
For high-volume use cases, dedicated batch endpoints process many files in a single request. Each returns a batchId you can use to track progress and fetch individual run results.
To retrieve individual run results from a batch, use the corresponding list endpoint filtered by batchId (e.g., GET /extract_runs?batchId={id}).
GET /batch_runs/{id} does not apply to workflow batches. Workflow batches are tracked via the workflow run list endpoint and workflow_run.* webhook events, which include the batchId in their payload.
API responses are now cleaner and more consistent:
Single object responses are unwrapped. Instead of { "extractRun": { ... }, "success": true }, the API now returns the object directly:
List responses use a standardized format. All list endpoints now return { "object": "list", "data": [...] }:
SDK users: These changes are handled automatically by the SDK. You’ll access results directly (e.g., result.output instead of result.extractRun.output).
For event-driven processing, the SDK includes utilities for verifying signatures and parsing events with type-safe payloads:
See the Webhooks Migration guide for full details and examples in all languages.
The latest SDK automatically uses the 2026-02-09 API version.
You don’t have to migrate everything at once. Start with the endpoints you use most and work through the detailed guides:
Processing Runs:
/processor_runs → /extract_runs (+ new sync /extract)/processor_runs → /classify_runs (+ new sync /classify)/processor_runs → /split_runs (+ new sync /split)/parse_runs (+ sync /parse)/edit_runs (+ sync /edit)Resource Management:
/processors → /extractors/processors → /classifiers/processors → /splittersOther Endpoints:
/files endpoints/workflow_runs request/response shapesIf you use webhooks, follow the Webhooks Migration guide to update your webhook handlers. This includes:
processor_run.processed → extract_run.processed)POST /webhook_endpoints, POST /webhook_subscriptions) in addition to the dashboardJump to the specific guide for the endpoints you use: