What is a signing session?

Why signing needs a session at all

The link in the invitation identifies a recipient, but a link alone is a poor credential for the act of signing: it lives in an inbox, it can be forwarded, and it may sit unread for weeks. The session is what the system issues once the person on the other end has demonstrated something more, whether that is simply opening a personal link or entering a code. From then on the document can be loaded and fields submitted without asking again on every request, which is what makes signing feel like a single continuous act rather than a series of checkpoints.

Bound to one person, one envelope

A session is not a general login. It is tied to a specific recipient on a specific envelope, so it cannot be carried to another document or used by another person on the list. That narrowness is deliberate: it means a session that leaks grants access to one signing act rather than to an account. It also means two signers on the same envelope hold entirely separate sessions, and one finishing has no effect on the other's clock. The session exists only in the browser holding it, so nothing on the server has to be cleaned up when it lapses.

Why refreshing sends you back

Because the session is held in memory in the page rather than written to storage, reloading loses it, and the portal returns to the verification step. That surprises people, particularly on mobile where switching apps can discard the page. It is a deliberate trade: keeping the pass in memory means it does not sit on a shared or borrowed device after the signer walks away. Re-verifying takes seconds where the check is a personal link, and a little longer where a code has to be re-sent, which is the honest cost of not leaving credentials behind.

What happens to work in progress

Fields completed but not submitted are held in the page, so losing a session usually means re-entering them. For a short document that is a minor annoyance, and for a long one it is a reason to prepare before starting: have the reference numbers, dates and details at hand rather than hunting for them mid signing. Where a signer is likely to be interrupted, a document with fewer typed fields and more pre placed content is a kinder design, since the fields that survive are the ones nobody had to fill.

Sessions are not the thing that expires most often

In support conversations, the phrase my link expired almost always means the envelope did. Sessions lapse quietly and are replaced by verifying again, so they rarely cause a support request. The envelope clock is the one people meet: after thirty days an outstanding envelope and its recipients are moved to expired by the nightly sweep, and opening the link then returns a clear message rather than a signing page. Distinguishing the two saves a pointless round of resending links that were never the problem. The quickest way to tell them apart is to ask what the screen said. A prompt to verify again means the session lapsed and the fix is in the signer's hands. A message that the request has expired means the envelope is finished, and only the sender can act by sending a fresh one.

What the timings are here

The session lasts thirty minutes and is bound to one recipient identifier. Verification comes first: an emailed link only, an access code of at least four characters shared out of band, or an emailed six digit code that expires in ten minutes, with at most five codes issued in any ten minute window. Five failed attempts lock that recipient for fifteen minutes, and the lock is written so parallel guesses cannot skip the counter. During a hosted in person session the emailed check is waived and the session is issued directly to the host's browser.

Questions people ask