Template builder
Repeatable workflows

Turn one winning extraction setup into a reusable template.

For invoices, claims, IDs, intake forms, and operations documents, teams eventually stop tuning every upload by hand. LeapOCR templates let you save the full playbook in one place, including model, format, description, instructions, schema, tags, review settings, and a reusable slug.

Why teams use this

Keep recurring document workflows consistent across teams and services.

Save model, format, instructions, schema, tags, and review settings in one builder.
Run the same setup again with `template_slug` instead of rebuilding the request every time.
Inside the builder

This is the real template shape inside LeapOCR: basics, instructions, schema, tags, color, favorite state, enabled state, bounding-box behavior, slug, and usage context.

Reusable workflow surface

Template builder

Save parsing rules once, reuse them everywhere

Basicsstructured
Name
Invoice intake
Model
standard-v2
Format
Structured JSON
Description
Standardize invoice fields for AP review and ERP writeback.
InstructionsOptional
|
Schema previewStructured
{
"vendor_name": "string",
"invoice_number": "string",
"due_date": "date",
"total_amount": "number",
"line_items": [{ "description": "string", "quantity": "number" }]
}

Why it works

Why teams switch to templates

The value is not that a template exists. The value is that the winning extraction setup stops living in one developer's request body and becomes a shared product asset.

Repeatability

One setup, many runs

Once a team locks in the right instructions, model, schema, and review settings, every future upload can follow the same playbook.

Real builder fields

More than a saved prompt

The actual product surface includes name, description, model, format, instructions, schema, tags, color, favorite, enabled, and bounding boxes, plus slug and usage context in the detail view.

Output shape

`markdown` or `structured`

Templates support the two result modes teams actually use: readable markdown for handoff and schema-fit structured output for downstream systems.

What you control

What lives in a template

These are the controls teams actually touch in the builder and in the template detail view when they standardize a document workflow.

name
Required · string

Give the workflow a durable identity

Name the workflow the way your team will search for it later: invoice intake, packing slip intake, prior auth packet, or KYC identity review.

format
Required · `markdown` | `structured`

Choose readable output or schema-fit output

Use markdown when the result needs to stay readable. Use structured when another system needs fields it can trust without another parsing pass.

model
Required · string

Lock the model to the workflow

Teams pin the OCR model on the template so the workflow does not drift when different callers or services touch the same document class.

instructions
Optional · up to 2000 chars

Save the extraction policy once

Instructions hold the nuance: normalization rules, ambiguity handling, table behavior, and review hints. The point is to keep those rules centralized.

schema
Structured workflows · object

Shape the output your system expects

For structured workflows, the schema is what turns OCR into a stable handoff. It defines the object your ERP, queue, or reviewer can rely on.

extract_bounding_boxes
Optional · boolean

Keep review-friendly coordinates when needed

Turn this on when review tooling, overlays, or exception handling needs field coordinates. Leave it off when the workflow is pure data handoff.

Examples

Where templates pay off fastest

The strongest use cases are the ones where a document class shows up every day and the team is tired of rebuilding the same extraction logic around it.

Finance operations

Save invoice extraction once, then hand the same workflow to every caller

This is the common pattern for AP teams that want one invoice workflow reused across the dashboard, SDKs, background workers, and exception queues.

The builder stores the exact setup that won in production.
Every future upload can call the same template with one short selector.
Changes to instructions or schema happen centrally instead of across services.
Saved template settings
json
  {  "name": "invoice-intake",  "format": "structured",  "model": "standard-v1",  "instructions": "Extract invoice header fields and line items.",  "schema": {    "type": "object",    "properties": {      "vendor_name": { "type": "string" },      "invoice_number": { "type": "string" },      "line_items": {        "type": "array",        "items": { "type": "object" }      }    }  }}
POST /ocr/uploads/url
json
  {  "url": "https://example.com/invoice.pdf",  "file_name": "invoice.pdf",  "template_slug": "invoice-intake"}
Operations handoff

Reuse the same template across direct uploads, queues, and review flows

Once a template is in place, it becomes the stable handoff layer for warehouse teams, customer ops teams, and automation services touching the same document family.

The request stays lightweight because the workflow already lives in LeapOCR.
The same template can power API-driven ingestion and human review tools.
Bounding boxes can stay on for visual validation without changing the main setup.
POST /ocr/uploads/direct
json
  {  "file_name": "packing-slip.pdf",  "content_type": "application/pdf",  "file_size": 482193,  "template_slug": "packing-slip-intake",  "extract_bounding_boxes": true}
Stored template excerpt
json
  {  "name": "packing-slip-intake",  "slug": "packing-slip-intake",  "format": "structured",  "model": "standard-v1",  "extract_bounding_boxes": true,  "enabled": true,  "favorite": false}

FAQ

Questions teams ask before wiring this up

Straight answers for teams evaluating how this workflow fits into production.

What does a template actually store?

A template stores the workflow settings your team wants to reuse: name, description, model, format, instructions, schema, tags, color, favorite state, enabled state, and optional bounding-box behavior.

How do developers use a template once it exists?

They reference it with `template_slug` during processing. That keeps requests small and ensures every caller uses the same extraction setup instead of carrying its own copy.

When should I use structured templates instead of markdown templates?

Use structured when another system needs fields, arrays, and nested objects it can trust. Use markdown when the result needs to stay readable for people, QA, or LLM handoff.

Can templates still include review-oriented settings like bounding boxes?

Yes. Bounding boxes can live on the template so review flows keep their field coordinates without every caller manually re-specifying that behavior.

Ready to test

Save the workflow once. Stop rebuilding it on every upload.

Templates give recurring document work a stable center of gravity. Save the setup your team trusts, then let every upload and integration reuse it.