Fill
POST /v1/fill takes a blank form and the documents that hold the answers, drafts every field, and returns the completed PDF. With review: "required" the run parks before producing the file so a person can correct the draft first.
How it works
- You send a template —
{"id": "…"}for a saved template, or{"url": "…"}for a one-off — and the files to draft from. - CloudRaker parses the sources, reads the form’s fields (detecting them when the PDF has none), and drafts a value per field.
review: "none"(the default) writes the values straight into the PDF.review: "required"parks the run atneeds_inputuntil the values are submitted.- The completed file comes back as
output.file,flattened(values baked in) oreditable(still a fillable form). - The run and its files expire on their own (
ttl, 24 hours by default) unless you keep them.
Quickstart
The sample fills a blank IRS Form W-9 from one source document — both public URLs, nothing local.
The TypeScript and Python samples are plain HTTP so they run with nothing installed. This endpoint is also a top-level method on both SDKs as of 0.3.0 — client.fill(…); that page has a full worked example.
Example response
Key fields
The output file’s bytes are registered a moment after the run reports processed. In that window output.file can arrive without its url and the /output/ alias can answer 404 — re-fetch GET /v1/runs/:id and the URL will be there.
Configuration
An ephemeral template: {url} is fetched at run time and is not added to your template library. The fetched copy is registered as a file in your API workspace and listed by GET /v1/files while the run is alive, but it belongs to the run: it is reclaimed when the run expires, and POST /v1/runs/:id/keep moves it into the target space with everything else. Pass {id} when the same blank form is filled repeatedly — a saved template is persistent and is never touched by a run’s TTL.
Human review
With review: "required" the call returns 202 immediately and the run settles at needs_input:
tasks[] lists every human step blocking the run. Each url is a hosted review page: open it in a browser (or send it to whoever should review), correct the drafted values, and submit — the run produces the document and finishes. The link is unguessable and carries the whole capability, so treat it as a secret; it stops working once the task is submitted or the run expires.
Prefer to build your own review UI? Drive the same task over the API instead:
Read the task
GET /v1/runs/:id/task returns the drafted values, the fields inventory (name, type, label, page, box), and the template’s pageBoxes / pageCount — everything needed to render your own review UI. GET /v1/runs/:id/task/pdf streams the exact template bytes those boxes were measured on. Both 404 once the task is submitted or expired.
The hosted page and the task routes are two views of the same task — either one submits it, and whichever comes second 404s. Runs started inside the product park identically but are reviewed in the app, so they carry no tasks[].
Sync vs async
Synchronous by default with ?wait= between 0 and 120 seconds, exactly like extract. review: "required" is the exception: a run that parks for a human returns 202 immediately rather than holding the request.
Save as an action
Save the instructions, review policy, output mode, and even the template once, then call {"files": …, "action": "vendor-onboarding"}:
Use GET /v1/actions/catalog for the exact config schema of the fill-form slug — see Saved actions.