Best Practices
This guide covers practical tips for getting reliable results from Edit: choosing how to drive a run, controlling the output, and running at scale.
Prefer a schema for precision
Natural-language instructions are the fastest way to get started, but a schema with extend_edit:value on each field gives you exact, repeatable control over what gets filled and where. Reach for a schema whenever you run the same form type repeatedly or need deterministic output.
Don’t have a schema yet? Generate Edit Schema detects a form’s fields and returns one with positions annotated, so you can start from a real layout instead of hand-writing field positions. See Schema.
Use instructions for context
When field mapping isn’t obvious — ambiguous labels, fields that depend on conditions — add instructions to guide how those fields should be filled. You can combine instructions with a schema: the schema pins the values you know, and instructions steer the rest.
See Instructions.
Flatten final documents
Set advancedOptions.flattenPdf to true when you’re generating a document for delivery, so the filled fields can’t be edited further. Flattening is on by default; set it to false if you need the output to remain an editable form.
See Flatten the PDF.
Enable table parsing for tabular forms
For forms with large table regions you want filled, set advancedOptions.tableParsingEnabled to true so Extend parses those regions as arrays of objects you can populate.
See Table parsing.
Download the edited file promptly
output.editedFile.presignedUrl expires 15 minutes after the run completes. Fetch and store the file as soon as the run reaches PROCESSED — don’t hold the URL for later use. The edited file’s id is reusable as input to other endpoints if you need to reprocess it.
Recipes
Ready-to-run config blocks for common scenarios (comments explain each setting). For field-level options and defaults, see Configuration.
Precise, repeatable fill
Quick fill from instructions
Tabular form
Move to production with async processing
The quick start and the examples above use the synchronous /edit endpoint — the fastest way to try Edit and iterate on config. When you’re ready to run Edit in production, switch to the asynchronous /edit_runs endpoint.
Why the sync /edit endpoint isn’t built for production:
- It has a 5-minute timeout — large or complex documents can exceed it and fail.
- It holds a connection open for the entire run, which is brittle for big files and bursty traffic.
- It’s intended for onboarding and testing, not sustained workloads.
What async (/edit_runs) gives you:
- Reliable handling of large documents without timeouts.
- Results via polling (
GET /edit_runs/{id}) or webhooks, so you’re not holding connections open. - A better fit for batch and high-volume pipelines.
The SDK helpers (client.edit_runs.create_and_poll() / client.editRuns.createAndPoll()) create a run and poll until it reaches a terminal state for you. See Async Processing for the full comparison, polling options, and webhook setup, and Error Handling for handling failed runs.

