Documents applicants sign

A verification can ask the applicant to sign a document. You write the document once, publish a version of it, and point a Document signing step at that version. Every applicant who reaches the step gets the document filled in with their own details, signs it by typing their name, and receives a sealed PDF with a certificate of completion.

Documents live under Documents in the console sidebar, next to Workflows, because authoring a document and authoring a workflow are the same job. A document is only ever reached from a workflow step.

Before you start

Three things have to be in place, and the console tells you which one is missing:

• An authorized signatory. This is the person who signs on your organization’s behalf, and it is set once for the whole organization under Settings → Organization → Authorized signatory. Signing steps cannot run until it is set. Changing it later does not rewrite documents that were already signed.
• An Identity information step earlier in the same workflow template. The document’s applicant fields are filled from what that step collects, so the signing step cannot be saved without it.
• A role that can author. Owner, Admin, and Manager can create, edit, and publish documents. Member can read them. Setting the organization signatory is Owner and Admin only.

Create a document

1. Open Documents and select Create a document.
2. Give it a Name and, optionally, a Description. Both are for your team; the signer never sees either.
3. Pick a Document type. This is recorded with the document and cannot be left blank. The options are Rental or lease agreement, Service or sales agreement, Employment or contractor agreement, Nondisclosure or confidentiality agreement, Consent or authorization, Disclosure or acknowledgment, Waiver or release, and Something else. The last one is there so you are never forced to mis-describe a real agreement to get it signed.
4. Read the list of documents that cannot be signed electronically and confirm yours is not one of them. This is a legal boundary, not a policy of ours: US law puts wills, family-law matters, court documents, and several kinds of cancellation and default notice outside electronic signing. The full list, and the two cases that look like carve-outs but are not, are on Electronic signatures.

Write the content

The editor is a plain rich-text editor. The toolbar gives you bold, italic, underline, a heading, bulleted and numbered lists, a quote block, a table, and a divider. Numbered lists are the normal shape for numbered clauses, and a table is the normal shape for a fee or payment schedule.

Two buttons do different things:

• Save draft stores your work. A draft is editable and is not signed by anyone.
• Publish version freezes the current content as a numbered version. A published version can never be edited, which is what lets a signed document be checked years later against exactly the text that was signed. To change a published document, edit the draft and publish again; the new version does not disturb anything already signed under the old one.

Fill in details with variables

A variable is a placeholder that resolves once, when the applicant’s document is prepared, and never afterward. That is what makes the signed PDF a fixed record rather than a page that re-renders differently later.

There are two ways to place one, and both open the same picker:

• Select Insert variable, under the toolbar. The picker lists every variable, narrows as you type, and moves with the arrow keys. Enter places the highlighted one, Escape closes the picker.
• Type {{ where you want the variable to go. This opens the same list in place, which is quicker once you know what you are looking for. It does not fire in the middle of a word, so use the button if the text right before the cursor is not a space.

A placed variable shows as a labeled chip rather than as raw braces, so you can read a clause and see which variable fills it. The chip names the variable and never shows a value. To read the document with the variables filled in, use the preview under See how the document reads before you publish. The picker names each variable exactly as the list below does, and it tells you what that variable needs. Read that part. For the two groups that need a workflow step, a variable whose step is absent makes the signing step refuse to save.

Always available. These need nothing from the workflow template.

• Organization name
• Organization address
• Signatory name
• Signatory title
• Signatory email
• Signatory phone
• Date prepared (UTC) (the date the applicant’s document was prepared for signing, printed as 2026-03-14 (UTC). Not the date you wrote the document, and not the date the applicant signs.)
• Verification session ID
• Envelope ID (the reference for this one signing session)

Needs a collect details step in the workflow. These come from the Identity information step, so that step has to be in the workflow template with the matching field switched on.

• Applicant legal name
• Applicant email
• Applicant phone
• Applicant date of birth
• Applicant address

Needs an ID check in the workflow. These are read off the document the applicant photographs, so the workflow template needs an Identity verification step before the signing step.

• ID document type
• ID document country
• ID document number (last 4)
• ID document number (full)

Needs a value in the session metadata. No workflow step produces these, and the applicant never supplies them. They come from the metadata object you send when you create the verification. A verification started from your API can carry them. A verification you start by hand in the console cannot: that form has no place to put them. A verification started by a connected system carries only part of the set, which is covered below.

• Start date and time (from start_datetime)
• End date and time (from end_datetime)
• Transaction amount (from amount)
• Currency (from currency)
• Location (from location)

Two things about these an operator cannot tell from the picker:

• The amount is in the minor units of the currency, which is its smallest unit. Send 125000 with a currency of usd and the document prints $1,250.00. For a currency with no decimal places, such as jpy, 50000 prints as ¥50,000. Send the amount and the currency together: an amount on its own has nothing to print.
• Every date and time prints with the time zone it was sent in. You choose that zone by choosing the offset on the value you send, so 2026-03-14T15:00:00-07:00 prints as 2026-03-14 15:00 (UTC-07:00). A value that is exactly midnight in the offset you send prints as the date alone, with no clock. A source system that records only a calendar date has no hour to state, and a printed 00:00 would read as a real start time. The offset is what decides that, not the instant: 2026-03-17T00:00:00Z prints as a bare date, and 2026-03-16T19:00:00-05:00 is the same instant but prints a clock.

Read this before you place one of these five in a document a booking system will fill. A connected booking system supplies only part of the set, and what is missing refuses the verification rather than printing blank:

• No booking system supplies the amount, the currency, or the location. A reservation has no single figure that is “the total”, and the address belongs to the property record rather than to the booking. Nothing is mapped for either. A document that places Transaction amount, Currency, or Location refuses every verification a booking system tries to start, and no applicant is invited. Place those three only in a document used by verifications you start from your API.
• A start or end that a booking system supplies is a calendar day, not a clock time. The reservation carries a check-in date and a check-out date with no hour on them. The value therefore arrives at local midnight, and the document prints a bare date such as 2026-08-01 (UTC-04:00). Do not write a clause around a check-in hour: the document has no hour to print.
• One booking system supplies none of the five. Its reservations carry no time zone, and the platform needs one before it can label a date. It therefore sends nothing, rather than a value that could print the wrong calendar day.

Which of these applies depends on which system you connected. Integrations covers each one, and Verification metadata has the per-field detail for whoever writes your API calls.

Three rules worth knowing before you write a clause around one:

• A variable that needs a workflow step blocks the save, not the applicant. If your document quotes the applicant’s address and the workflow template does not collect an address, the workflow will not save and the console names the variable. You never find out by handing an applicant a document with a hole in it.
• The platform checks a session metadata variable later, when you create the verification. No workflow step can supply these, so the save has nothing to check and a workflow that uses one saves normally. The platform refuses the create instead, when the request omits a value the document requires. The applicant is still protected the same way: the refusal happens before anyone is sent a document.
• The full ID document number is off by default. Use ID document number (last 4) unless you have a specific reason not to. Turning the full number on is a separate, recorded decision that only an Owner or Admin can make, because it puts a complete government identifier into a document that gets emailed.

See how the document reads before you publish

A published version can never be edited, so check the document before you publish it.

The document’s page carries a Preview card with a Preview with a session control. It opens the document filled in from one of your ten most recent verifications. The picker offers them newest first, from the mode you are working in. The roles that can publish a document can open the preview. A role that can only read documents sees the document with variable labels in place of values.

Every variable outside the two applicant groups fills in with a real value, when the verification carries one. That covers your organization details, your authorized signatory’s details, the date, and the five transaction values. Envelope ID is the exception, because the platform assigns it when the applicant signs. The preview prints a note in its place.

This is not the document your signer sees. The preview marks these variables as hidden in preview, and it never reads them:

• Applicant legal name
• Applicant email
• Applicant phone
• Applicant date of birth
• Applicant address
• ID document country
• ID document number (last 4)

Those values stay encrypted, and the platform fills them in when the applicant reaches the document. ID document type is the one applicant value the preview shows, and it shows the real value. On its own it names a kind of document rather than a person.

The preview marks ID document number (full) as needs permission, not as hidden. The full number is off unless the signing step allows it. A document carries no workflow, so the preview cannot tell which signing step will run this one. It therefore states a requirement rather than a prediction. If the step that runs the document does not allow full ID document numbers, the platform cannot prepare the document. The verification stops there, and the applicant never receives the document. Allow full ID document numbers on the signing step that uses this document. The other option is to place ID document number (last 4) instead, and publish a new version.

The preview also lists every variable the verification you picked cannot fill, and it names what to do about each one. That covers both of the variable failures under Troubleshooting, before an applicant meets either.

The list is one-sided. It can tell you that a variable will not resolve. It can never tell you that a variable will resolve. The preview reads whether the applicant record holds a value, not the value itself. A variable the preview does not list can still turn out to be empty at signing.

Add the step to a workflow

Open the workflow template, switch on Document signing, and choose a published version. The step’s settings are covered in Choose the right check types: the read-through requirement, a minimum signer age, and who gets emailed a copy.

The applicant’s side of it, step by step, is in What the applicant sees.

After it is signed

The signed PDF and its certificate of completion are attached to the applicant’s record, and a copy is emailed to whoever you chose. The certificate records who signed, when, from what kind of device, which version of the electronic-records notice they agreed to, and the retention window that applies.

Anyone holding the PDF can check it independently, with no account and no API key, using the hash of the file. The steps are published at Electronic signatures, and the address of that page is printed inside every certificate.

An applicant can also decline. A decline is a recorded outcome with a reason, not an error, and the verification ends there.

How long a signed document is kept

Signed documents and their audit trail are kept for the window set on the workflow template that produced them: Signed document retention, in the Data & privacy section of the workflow editor. The range is 30 days to 2555 days (7 years), the default is the full 7 years, and it is the same on every plan. E-signature is not a plan-gated capability, so no plan shortens how long your signed agreements are kept.

Two rules the editor enforces:

• It can never be shorter than the Data retention window above it. Signed documents outlive the identity evidence collected alongside them, not the other way around.
• Lowering it applies to verifications created afterward, never to documents already signed. An executed agreement keeps exactly the window its own certificate printed.

Deleting a signed agreement early destroys the evidence the signature exists to provide, which is why the default sits at the ceiling. A deletion request from an applicant still outranks the window, as it does everywhere else.

Troubleshooting

• The workflow will not save and names a variable. The document uses a variable the workflow template cannot supply. Either switch on the matching field in the Identity information step, add an Identity verification step, or remove the variable from the document and publish a new version. This covers the variables a workflow step supplies. A session metadata variable never blocks the save, so if the save succeeded and the failure came later, read the next item instead. The preview names a variable like this before you publish the version.
• The workflow saved, but a verification will not start and names a variable. The document places one of the five variables that read the session metadata, and the request carried no value for it. Add the named key to the metadata object on your API call. Or remove the variable from the document and publish a new version. The message names both the variable and the key to send. If a connected system starts these verifications, check what it supplies before you place the variable. See the note under Fill in details with variables. The preview names this variable too, once you pick a verification that carries no value for it.
• Document signing will not turn on. The workflow template has no Identity information step yet. Add one and place it before the signing step.
• The version picker is empty. The document has drafts but no published version. Open it and select Publish version.
• The step is on but no document is chosen. A signing step with no document cannot be saved. Pick a published version, or switch the step off.
• A signatory is required. Set one under Settings → Organization → Authorized signatory. If you do not have permission, an Owner or Admin in your organization does.
• The verification is waiting for funds. Signing steps are paid checks, so a wallet with no spendable balance pauses the verification instead of skipping the step. Fund the wallet and the applicant carries on from where they stopped. A signature already recorded is safe. See Payment required.