The flow, end to end

How Signattio works: from draft to verifiable PDF

One envelope goes through five stages — send, identify, sign, seal, verify. Here is each stage and what it leaves behind.

Send: draft, document, recipients

You create an envelope and upload the PDF. Then you add recipients in a routing order — in parallel or in sequence — each with an identity level: a one-time code by email, a one-time code by SMS, or a single-use magic link.

Sending delivers a personal link to each signer by their channel. The signer never needs an account; the link and the identity check are what gate access.

Identify: proving who is on the other end

Before the ceremony opens, the signer passes the identity step the envelope asked for. For code-based methods, Signattio issues a one-time code bound to that envelope and that signer and records the channel it went to; for the magic link, the click on the single-use link is itself the confirmation and is recorded the same way.

Each of these events — issue, attempt, confirm — is written to the audit trail, so the record later shows not just that identity was checked but how.

Sign: the ceremony

The ceremony page shows the document pages, the fields to complete, and a space to draw the signature. The signer reviews, fills, draws and confirms. Every event — opened, field placed, signature drawn, confirmed — lands in the audit trail while the ceremony runs.

The drawn signature is the visible act; the evidence around it is what makes it provable. That distinction is deliberate: the ceremony is designed to be experienced, and to be reconstructed.

Seal: what happens after the last signature

When the envelope completes, each signer's act is applied as a PAdES signature over the exact signed bytes — and, when an RFC 3161 authority is configured, a trusted timestamp from that authority is embedded, so the time does not rest on the signer's laptop clock.

Where the signing service can embed validation data, the envelope is upgraded to B-LT: the certificate chain and the revocation information (OCSP or CRL responses) are embedded in the PDF itself, so the proof remains demonstrable years later without those services. Otherwise the evidence pack records the lower PAdES level actually reached. A sealed evidence certificate — the hash-chained audit trail — is attached inside the file.

Verify: checking it without an account

The delivery email carries the final PDF and a personal verification link; the verification code is also printed inside the evidence certificate. Anyone with the code — or any validator with the file — can recompute the facts: the digest, the certificate chain, the timestamp and the audit chain.

Verification is designed not to depend on Signattio: the file carries its own evidence. If you want the exact steps for checking a returned document, that is its own guide.

Sources

  • The Signattio product documentation (the /docs section of this site).
  • ETSI EN 319 142-1 — PAdES digital signatures; cited by name, paywalled standard.
  • RFC 3161 — TSP Time-Stamp Protocol (Adams, Cain, Pinkas, Zuccherato, 2001).

This is a description of the product's flow, not legal advice.

Read next

The Signattio API: envelopes in, sealed evidence out

The same flow, driven from your own backend.

PAdES explained: the PDF signature profile, level by level

The standard behind the seal, level by level.

OTP identity verification: what a one-time code actually proves

What each identity method proves — and what it does not.