Trust boundaries
How your platform and NoSign divide authority.
NoSign is intentionally split into two separate trust boundaries that never share authentication state.
Your platform — the gatekeeper
Your platform (or central API) is the only entity that can create signing requests. It holds the API key, supplies the document and signer list, and receives the webhook. It is also responsible for delivering the signing_url to the first signer through whatever channel it controls (email, SMS, in-app notification).
Nothing about signer identity or document content flows from the signer-facing side back to your platform — only the sealed result and the audit bundle travel over the webhook, authenticated by HMAC.
NoSign — the ceremony host
NoSign only ever serves signer-facing pages publicly: the email-verification step, the PDF viewer, the consent checkboxes, and the signature pad. It does not expose any endpoint that signers can use to modify the signing request, change field coordinates, or alter which signers are in the queue.
Signers authenticate to NoSign only via the one-time link in the verification email. There is no shared login, no session shared with your platform, and no way for a signer to elevate their access.
Why this split matters
- No cross-contamination. A compromised signer link cannot affect your platform’s API state. A compromised API key cannot impersonate a signer or alter a document mid-ceremony.
- Minimal surface. NoSign’s signer-facing surface is small and scoped: verify email, view PDF, sign. There is no account creation, no password reset, no profile page.
- Clear audit attribution. Every recorded event knows which boundary it belongs to: API-key-attributed requests on one side, signer-action events on the other.