The slow part isn't signing — it's placement

The signing itself is fast. What eats time is the setup before it: uploading a document, then dragging a signature box, a date field, an initials field, and a few text inputs onto exactly the right spots — for every document, every time. For a one-off agreement that's tolerable. For a contract you send a hundred times, or one your own application generates on the fly, hand-placing fields is the bottleneck.

There are two ways to kill that bottleneck. One is reusable templates, where you place fields once and reuse the layout. The other — for documents that are generated by another system, or change layout often — is field tags: text markers inside the PDF that tell Hosting Sign where to put each field automatically.

How field tags work

A field tag is just a piece of text in your document, written in a simple syntax, that the platform recognizes and converts into a real, interactive field. Instead of dragging a signature box onto the page, you type a marker where the box should go, and the field-tag API reads the PDF's text layer on upload and drops the field exactly there.

The vocabulary covers the common field types:

  • {{signature}} — a signature field.
  • {{text:Label}} — a text input, labeled for the signer.
  • {{radio:A|B|C}} — a radio group with the given options.

Put {{signature}} at the bottom of your contract and the signature field lands there. Put {{text:Job Title}} next to a line and the signer gets a labeled box in that spot. The document defines its own fields; you place nothing by hand.

Why this matters for generated documents

The real power shows up when another system produces the PDF. If your contract is assembled from a Word template, a billing system, or your own app's document generator, you control the text — which means you control the tags. Bake the markers into the source template once, and every PDF that system produces arrives already knowing where its fields go.

That's what makes field tags the natural partner to programmatic signing. Combined with embedded signing, your application can generate a document, hand it to Hosting Sign, and have a fully fielded envelope ready to sign — with no human ever opening a field editor. The layout can change with every document and the fields still land correctly, because they're defined by the content, not by a fixed template overlay.

Tags vs. templates: when to use which

Both eliminate hand-placement, but they fit different shapes of work:

  • Use a template when the document is stable and you send the same layout repeatedly — an NDA, a standard order form, an onboarding packet. You place fields once in a visual editor and reuse them, and you get extras like saved routing and merge fields.
  • Use field tags when the document is generated or varies — output from another system, contracts assembled per deal, anything where the page layout isn't fixed. The tags travel inside the file, so the fields follow the content wherever it ends up on the page.

Many teams use both: templates for their standard agreements, tags for the documents their other tools spit out.

Getting the tags right

A few practical notes so the auto-placement is clean:

  • Tags read from the text layer. They need to be real, selectable text in the PDF — not part of a scanned image or a flattened graphic. If your generator outputs true text, you're set.
  • Place the tag where you want the field. The field anchors to the tag's position, so put the marker exactly where the box should sit, and give it room.
  • Test once per template. Send a single envelope to yourself, confirm every field landed where you intended, then trust the layout for the rest.

Field tags turn "set up the document" from a drag-and-drop chore into a property of the document itself. Write the markers once — or have your system write them — and every PDF places its own fields, every time, with no editor in the loop.