A form schema is a reusable field set that can drive many templates. Define it once (e.g. "Invoice"), attach it to any template, and every render against those templates accepts the same request body shape.

Why schemas

One integration on your side works across every branded variant.
Rename a field once and every bound template updates.
Validation runs before the render is enqueued.

Field types

string, number, boolean, date
url, email, color
image — public HTTPS URL
enum — fixed choice list
section — group of nested fields
repeatable — array of a section (line items, rows, cards…)

Passing a schema id at render time

When a template is bound to a schema, pass form_schema_id so friendly field keys resolve:

json

{
  "template_id": "d8a4c9f2-1b3e-4a1f-9c0b-1234567890ab",
  "form_schema_id": "sch_invoice_v2",
  "format": "pdf",
  "data": {
    "customerName": "Acme Corp",
    "invoiceNumber": "INV-1042",
    "lineItems": [{ "description": "Retainer", "qty": 1, "unit_price": 1000 }]
  }
}

Versioning

Each schema has a schema_version that increments on updates, plus an optional published_schema snapshot when a template family is published. Integrations should pin a family/version when you need immutability; otherwise the live schema is what fill and render use today.

On the Business plan, schemas can be shared across workspaces you own, so a single "Certificate" schema serves multiple brands.

Why schemas

Field types

Passing a schema id at render time

Sharing across workspaces