Templates
A template is an organization-level document you fill in over and over — a W-9, an onboarding packet, a claim form. Templates are persistent (no TTL), never parsed or indexed, and are referenced by fill as template: { "id": "…" }.
Templates are deliberately a different noun from files: files are the inputs a run reads and are subject to a TTL when a run creates them; templates are curated assets that live until you delete them.
Add a template
Two shapes, same as files — send url, or name + mimeType for a presigned upload.
status moves uploading → ready. Templates are not parsed, so they reach ready as soon as the bytes land — usually seconds.
Read, list, delete
?limit caps the page (1–200, default 50). There is no cursor — the list is a single newest-first page. DELETE returns 204.
Inspect the fields
POST /v1/templates/:id/inspect returns the field inventory with page geometry. Fields are detected when the PDF carries no fillable form. The first call can be slow; later calls reuse the result.
box here is in PDF points, unlike extraction citations, whose bbox is normalized to 0–1.
Fill from a template
Fill also accepts template: { "url": "…" } for a one-off form. That copy is fetched at run time and is not added to your template library — use it for a form you’ll never see again, and a saved {id} for one you fill weekly.
The fetched copy is registered as a file in your API workspace and shows up in GET /v1/files while the run is alive, but it belongs to that run: the run’s TTL reclaims it along with the run’s other files, and POST /v1/runs/:id/keep moves it into the space you keep the run into. Nothing to clean up. A saved template is the opposite — a persistent asset of your library that no run expiry ever deletes.