Detect Form
Detect Form detects the fields in a PDF form and returns a form_detection_run whose output.schema you can pass straight to /edit or /edit_runs. The returned schema has field positions annotated, so you don’t have to write extend_edit:bbox coordinates by hand. Optionally, supply your own schema and Extend maps it onto the detected fields.
Reach for it when you:
- Need a starter schema for a new PDF form.
- Want to map an existing schema onto a vendor-specific layout.
- Need annotated field locations before running edits at scale.
- Want to add conditional form logic on top of detected fields.
Use POST /detect_form for synchronous testing. For production workloads, use POST /form_detection_runs and poll GET /form_detection_runs/{id} to avoid request timeout issues.
Quick start
We’ll detect the fields in a PDF form. Grab a key from the Developers page and store it as the EXTEND_API_KEY environment variable. If you’re using an SDK, see the installation instructions.
Python
TypeScript
Java
Go
cURL
Response
The response is a form_detection_run. A successful synchronous request returns after the run reaches PROCESSED; the asynchronous endpoint usually returns it with status: "PROCESSING".
Asynchronous processing
For production workloads, create a form detection run and poll it by ID:
Poll until status is PROCESSED or FAILED. See Async Processing for retry and polling guidance.
Request configuration
The config object is shared by the sync and async form detection endpoints:
A common workflow
The generated schema uses the same format as edit runs, including support for root-level JSON Schema conditionals. A common workflow is:
- Generate a base schema from the PDF form.
- Add conditional requirements for follow-up fields.
- Use the refined schema with
/editor/edit_runs.
For the exact request and response schemas, see Detect Form (Sync), Detect Form (Async), and Get Form Detection Run.

