Coordinate contract
How signature field positions are specified and validated.
NoSign uses Option A for field placement: your platform is responsible for resolving and supplying signature field coordinates. NoSign never parses the PDF to discover or infer positions.
What you supply
Each signer in the request payload carries a fields array. Each field entry describes a rectangular stamp area on a specific page:
| Property | Type | Description |
|---|---|---|
page | integer | 1-based page number |
x | number | Left edge in PDF points from page left |
y | number | Top edge in PDF points from page top |
w | number | Width in PDF points |
h | number | Height in PDF points |
type | string | The kind of input — see field types |
required | boolean | Whether the signer must complete this field |
Field coordinate values are illustrative. Verify the exact schema against your NoSign instance’s API documentation.
The contract covers where a field goes and what kind it is — the type selects how NoSign renders and validates it. If you place the same fields repeatedly, define them once as a template and create requests from it instead of re-sending coordinates.
Validation at ingestion
NoSign validates every field at ingestion time, before the signing request enters the workflow:
- Coordinates that fall outside the page dimensions are rejected with
422 Unprocessable Entity. - Missing required properties are rejected with
422. - A request with no fields for a signer is rejected.
This means errors surface at the moment your platform POSTs the request — not mid-ceremony after a signer has already started.
Why your platform owns positioning
Your platform knows the document structure. It may place fields via click-to-place UI, inline tag parsing, or a template system. NoSign’s job is to receive resolved coordinates and stamp them faithfully — not to guess intent from the PDF content.
This clean separation keeps NoSign small and makes field placement logic a first-class concern of the consuming application, where it belongs.