Signature tags

Every PDF you pick in the send composer is scanned once, automatically. If the document says where its signatures go, the fields are placed for you, with no button and no re-render: the document that gets signed is, byte for byte, the file you picked.

Three kinds of document say so, and you never choose between them. Whatever the document carries is what is read.

1. Documents Sliick Docs generated from a template with e-signature turned on and signing fields placed. These carry an invisible pointer to the exact template release they came from, so their fields land where the template author put them, even after the file has been downloaded, emailed and uploaded again. There is nothing to write. See Setting up a template for signature.
2. Documents any other system generated, using the Sliick signature tag described on this page. This is the one to use when your PDFs come from a billing system, a partner portal, a Word mail merge or anything else outside Sliick Docs.
3. Documents written for DocuSign or Adobe Acrobat Sign. See Reading DocuSign and Adobe Acrobat Sign tags.

A PDF that carries none of these is completely normal. You place the fields by hand, and nothing is said about it. That is the expected path for a counterparty’s contract.

The tag

Write this text in your document, at the spot the field belongs:

{{@Signature:Role:Order:Type}}

Part	What it means	Rules
@Signature	The keyword.	Not case-sensitive, so {{@signature:…}} works too.
Role	Who signs here.	Starts with a letter or a digit, then letters, digits, spaces, hyphens and underscores, up to 80 characters. Tags sharing a role name, ignoring case, belong to the same signer, so Client and client are one person.
Order	That role’s place in the signing order.	A whole number from 1 to 99. Roles are listed in this order in the composer.
Type	What the signer does.	One of the values below.

Type	Field placed
Signature or Sign	Signature
Initials or Initial	Initials
Date or DateSigned	Date signed, stamped automatically
SignerPicksDate	A date the signer chooses from a calendar, such as a start date or a date of birth
Name or FullName	The signer’s full name
Text	A free-text box
Checkbox	A checkbox

Type words are not case-sensitive. Amount and dropdown fields have no tag: add those in the composer.

The two dates are different fields, and the difference is who fills them in. Date is stamped with the date the document was signed, and the signer cannot change it. SignerPicksDate is empty when the signer arrives, and they pick a date in it. Every e-signature product uses the plain word date for the automatic one, so that is what Date means here. The signer-picked date has its own keyword with no short form, on purpose: write the whole of SignerPicksDate.

Example

{{@Signature:Buyer:1:Signature}}
{{@Signature:Buyer:1:Date}}
{{@Signature:Buyer:1:SignerPicksDate}}
{{@Signature:Seller:2:Signature}}
{{@Signature:Guarantor:3:Initials}}

That document arrives in the composer with a Buyer, a Seller and a Guarantor already on the signer list and five fields already on the page, including one date the Buyer picks and one stamped for them. Fill in each signer’s name and email, and send.

Where the field lands, and hiding the tag

The field’s bottom-left corner sits at the start of the tag, so a tag written on a signature line puts the field on that line. The field comes in at a sensible default size for its type; drag or resize it if you want something else.

Give each tag its own line, or at least its own run of text. A tag on its own line is placed exactly. A tag buried mid-sentence, such as Sign here: ______ {{@Signature:Buyer:1:Signature}}, is placed close to where it sits but not exactly, because the position inside a line of proportional text can only be estimated. A tag on its own line is also the easiest to hide.

The tag is ordinary text, so hide it the way other e-signature products do: set it in white, or your page’s background colour, and shrink it to 1 to 4 pt. Either works, and you can combine them. Two things to know first:

• White or tiny text can still be selected, copied and read by a screen reader. Do not put anything in a role name you would not want a recipient to read.
• Do not hide a tag by placing it off the page or behind an image. A tag the PDF’s text does not include cannot be found, and its field will not be placed.

Writing tags from other sources

The tag is plain text, so anything that can put text into a PDF can produce it. You need no integration, API or add-on on the other system: whatever builds the document writes the tag where the field belongs.

The one requirement is that the tag survives as real, selectable text in the finished PDF. To check, open the PDF, press Ctrl+F (or Cmd+F on a Mac) and search for @Signature. If your PDF viewer finds it, the composer will too.

From a Sliick Docs Word-file template

Type the tag straight into the Word document: {{@Signature:Client:1:Signature}} on the client’s signature line and {{@Signature:Client:1:Date}} beside it. It is the one {{…}} tag the merge deliberately leaves as written, so it passes into both the Word file and the generated PDF, and the PDF arrives in the composer with its fields placed. See Word-file templates.

Format the tag’s text in Word the way you want it hidden, white or 1 to 4 pt, and that carries into both the Word file and the PDF.

Do not use Word’s Hidden font effect. Sliick Docs PDF output does not honour it, so the tag would print visibly, and a PDF saved from Word itself leaves hidden text out entirely, so there would be nothing to find.

From a designed template

Do not type tags. Turn e-signature on for the template and place signing fields on its E-sign tab instead. The generated PDF then carries a pointer to them, which is the most precise of the three kinds of document. See Setting up a template for signature.

From Word mail merge, Google Docs or any word processor

Type the tag as ordinary text, hide it with white or tiny text rather than the word processor’s hidden-text setting (which drops it from the PDF), and export or save as PDF. Avoid print as image, flattening, or scanning a printed copy: each turns the text into a picture, and a picture has no text to find.

From a billing system, CPQ, reporting tool, HTML-to-PDF service or your own code

Emit the tag as literal text in the document template at the spot the field belongs. In an HTML-based generator, for example:

<span style="color:#ffffff;font-size:2pt">{{@Signature:Customer:1:Signature}}</span>

The role, order and type are fixed words you choose when you design the document. They are not looked up from anything. Customer, Client or Tenant becomes a signer row in the composer, and the sender fills in each person’s name and email there. Keep role names consistent across a document, Customer everywhere rather than Customer in one tag and Client in another, because two different names are two different signers.

Before you roll a generator out, send one real document through the composer and check the fields land where you expect.

Tags the composer refuses

These are deliberate. In each case the composer tells you, and leaves you to place the fields yourself.

• A Type it does not recognise. The tag is counted and reported, never guessed at, and the composer names the word back to you so you can see which one was mistyped. If it looks like a date, you are reminded of both date keywords.
• A tag malformed in any other way, such as a role name with punctuation outside the allowed set, an order that is not a number, or a missing part. Anything written as {{@Signature…}} that cannot be read is counted and reported the same way, so a mistyped tag never disappears quietly.
• A document over 250 pages. Scanning stops, rather than reading part of a document and presenting it as the whole.
• Fields missing from a document Sliick Docs generated. If a template’s signature setup expects fields the file does not carry, nothing is placed and you are told the document may predate a change to that template. A partly placed page looks complete, which is worse than an empty one.

Reading DocuSign and Adobe Acrobat Sign tags

If you are moving templates across from another product, the composer reads their tags too, so you do not have to rewrite every document at once. This is read compatibility to help a migration, not full support for those products’ tag languages.

Product	Tags read	Field placed
DocuSign	\s1\	Signature
DocuSign	\d1\	Date signed
DocuSign	\n1\	Full name
Adobe Acrobat Sign	{{Sig_es_:signer1:signature}}	Signature
Adobe Acrobat Sign	{{Int_es_:signer1:initials}}	Initials
Adobe Acrobat Sign	{{Dte_es_:signer1:date}}	Date signed
Adobe Acrobat Sign	{{N_es_:signer1:fullname}}	Full name

The number stands for the signer, from 1 to 99. Neither product’s tags carry a role name, so the composer adds signers named Signer 1, Signer 2 and so on, one per number the document uses, in number order, with each field assigned to its signer. The sender fills in each signer’s name and email as usual.

What is matched, exactly:

• DocuSign: only \s1\, \d1\ and \n1\, with any signer number. Other DocuSign anchors, including \i1\ for initials, text-field anchors and the custom anchor strings a sender invents per envelope, are not recognised and are left alone: no field is placed and nothing is reported. Place those fields by hand, or add Sliick tags alongside.
• A single DocuSign anchor is ignored. \s1\ is short enough to turn up in ordinary text, so a document needs two or more before it is treated as written for DocuSign. An Adobe tag is distinctive enough to count on its own.
• Adobe Acrobat Sign: the four tags in the table, where the word after signer1 must match its prefix: signature after Sig_es_, initials after Int_es_, date after Dte_es_, and fullname after N_es_. Case, and spaces around the colons, do not matter. A tag with the right prefix but a different word is counted and reported as not understood.
• Tag options are not read. A tag with anything after its third part, such as :optional, a formatting directive or a calculation, is skipped and reported, because an option changes what the tag means and reading half of it would create a field with the wrong rules.
• Neither product can bring a signer-picked date across. The date tag read from each means the date signed. A date the signer enters has no recognisable tag in either product, so a migrated template arrives with those dates unplaced. Add a SignerPicksDate tag, such as {{@Signature:Buyer:1:SignerPicksDate}}, or place them by hand.

One kind of tag per document. A document is read by exactly one kind of tag, in this order of preference: documents Sliick Docs generated, then Sliick signature tags, then Adobe Acrobat Sign, then DocuSign. A document carrying Sliick tags and leftover DocuSign or Adobe tags is read by the Sliick tags alone. The others are ignored rather than merged into a set of fields nobody wrote.

Moving fully to Sliick tags

Read compatibility is a bridge, not the destination. When you next edit a migrated template, replace its tags with Sliick tags. You get real role names in the composer, and field types the other products’ tags cannot bring across here: initials from DocuSign, text, checkboxes and signer-picked dates.

Was	Write instead
\s1\ or {{Sig_es_:signer1:signature}}	{{@Signature:Client:1:Signature}}, using a real role name
DocuSign initials (\i1\) or {{Int_es_:signer1:initials}}	{{@Signature:Client:1:Initials}}
\d1\ or {{Dte_es_:signer1:date}}	{{@Signature:Client:1:Date}}, the date signed
\n1\ or {{N_es_:signer1:fullname}}	{{@Signature:Client:1:Name}}
A date the signer enters	{{@Signature:Client:1:SignerPicksDate}}
A text field	{{@Signature:Client:1:Text}}
A checkbox	{{@Signature:Client:1:Checkbox}}

Use the same role name on every tag that belongs to one person, and number the roles in the order they sign, for example Client 1 and Supplier 2.

After the fields are placed

Fields placed from any kind of tag are ordinary placed fields. Move them, resize them, reassign them or remove them before you send, exactly like a field you placed yourself. See Sending a document.