/parse_runs (async) for all production workloadscreateAndPoll() helper — Easy polling with client.parseRuns.createAndPoll()output.chunks, predictable nullable fieldsfile object instead of just fileId{ object: "list", data: [...] } formatThis guide covers all breaking changes to the parse endpoints.
The SDK group and method names have been updated for consistency:
The ParserRun schema has been replaced with a unified ParseRun schema that handles both sync and async cases. Status-dependent fields are now required but nullable for a predictable response structure.
The following shows the ParseRun object structure.
Note: All fields are always present in the response. Status-dependent fields use null when not applicable.
The ParserRunStatus schema from the old API (used for async responses) has been removed. The unified ParseRun schema now handles all states with the PROCESSING status.
When a parse run is still processing, the response will have status: "PROCESSING" and output will be null:
The request body structure has been updated with renamed properties:
The responseType query parameter is no longer available on the create endpoint. Use it on the GET /parse_runs/{id} endpoint instead.
POST /parse) is still available and uses the new request/response format (same as /parse_runs). It’s intended for testing and onboarding. For production, use /parse_runs with polling or webhooks:The response structure has been updated:
The responseType query parameter controls how output is delivered:
json (default) - Returns chunks in output.chunksurl - Returns a presigned URL in outputUrl to download the outputKey differences:
success fieldfileId → file (full File object)chunks → output.chunksoutputUrl field (for responseType=url)The response has been significantly simplified:
Key differences:
success fieldparserRunId → idmessage field removedIf you encounter any issues while migrating, please contact our support team at support@extend.app.