Field types
The five field types a signer can fill — and how they're enforced.
A signing request is more than signatures. Each field a signer fills carries a type, and NoSign renders, validates, and stamps each type appropriately. Your platform still owns where a field goes (the coordinate contract) — the type says what kind of input belongs there.
The five types
type | What the signer does | Stamped as |
|---|---|---|
signature | Draws a signature on the signature pad | The rendered ink image |
initials | Draws their initials | The rendered ink image |
date | Nothing — the value is server-derived from the signer’s signing time | A formatted date |
checkbox | Ticks a box | A check mark (and its state in the audit trail) |
text | Types into a single-line field (optional label, optional max_length) | The entered text |
The date type is deliberately not free-typed: it is derived server-side from when the signer actually submits, so it cannot be back- or forward-dated.
How it’s enforced
The set of valid types is a fixed enum, and the database enforces it with a CHECK constraint — an unknown type can never reach storage. Stamping is per-type in NoSign’s PDF embedder, so each field is drawn into the sealed document according to its kind.
Specifying a type
Add a type to each field object in the create-signing-request payload (text fields may also carry label and max_length):
{ "page": 1, "x": 72, "y": 640, "w": 180, "h": 48, "type": "signature", "required": true}{ "page": 1, "x": 72, "y": 560, "w": 240, "h": 24, "type": "text", "label": "Job title", "max_length": 80, "required": false}Field names and the exact type spelling are illustrative. Verify against your NoSign instance’s API.
Still out of scope
Field types and templates ship in the box, but a drag-and-drop placement UI does not — your platform resolves coordinates and sends them. Out-of-bounds or malformed fields are rejected at ingestion with 422.