Most of our API assumes you know who is signing. You have a name, you have an email, you send them a document. That covers vendor onboarding, offer letters, renewals, and nearly every workflow that starts inside your own system.
Then there is the other kind. A supplier NDA on your partners page. A liability waiver on a booking confirmation. A photo release you hand to anyone who walks in. You do not have a list. You have a page, and you want whoever lands on it to be able to sign.
In short: publish a template as a link, embed that link in your own page, and each visit becomes its own tracked document. Two API calls to set up, and it works in the sandbox first.
Publish the link
Start from a published template. One signer role is left open for the visitor; anyone else who needs to sign is named now.
curl https://api.documentesign.com/v1/templates/tpl_4c8a.../links \
-H "Authorization: Bearer $ESIGN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"label": "Supplier NDA - partners page",
"headline": "Sign our mutual NDA",
"signers": [
{ "placeholder_id": "ph_1", "is_open": true },
{ "placeholder_id": "ph_2", "is_open": false,
"name": "Dana Poole", "email": "dana@acme.com" }
],
"max_uses": 500
}'You get back a short URL you can hand out as is. It keeps working until you disable it, it expires, or it runs out of uses.
Why only one role is open
This is the constraint people ask about first, so it is worth saying plainly. A link cannot leave every role open.
If it could, a visitor would be choosing your counterparty as well as themselves. Someone signing your NDA could nominate whoever they liked as the second party, and you would find out when the countersigned copy arrived. Naming the other signers at creation time means the visitor fills exactly one seat, and the rest of the agreement is already settled.
Embed it in your own page
The plain link is a full page, and it will not load in an iframe. That is on purpose: if any site could frame your signing page, any site could wrap it in their own chrome and collect signatures under someone else's brand.
So embedding is opt in. Add the origins allowed to frame your pages under Settings, Developer, Embedding, then mint an embed URL:
curl https://api.documentesign.com/v1/template-links/lnk_2f8d.../embed-link \
-H "Authorization: Bearer $ESIGN_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "expires_in": 900 }'<iframe
src={embedUrl}
title="Sign the agreement"
style={{ width: "100%", height: 780, border: 0 }}
/>The visitor fills their details and signs without leaving your page. The signing step stays in the frame too, so there is no moment where your careful layout is replaced by ours.
One detail worth knowing: the embed URL references the link, not its slug. Rotate the slug because it leaked publicly, and an embed you deployed six months ago keeps working.
Track it like anything else
Every visit produces an ordinary document. Nothing new to learn, and nothing new to poll.
| Event | What just happened |
|---|---|
document.sent | A visitor completed the form and their copy went out |
recipient.signed | One party finished |
document.completed | Everyone signed; fetch the sealed PDF |
Read use_count on the link when you want a running total rather than a stream.
Which one to reach for
The two paths are easy to mix up, so here is the split.
You know the signer. Send from the template with field_values and get prefill, so the price, the account number and the start date are already filled in. Pass embed on the same call and the signing URL comes back with the document, in one round trip.
You do not know the signer. Publish a link. No prefill, because there is nobody to prefill for, but no list to maintain either.
Build it against the sandbox
A link made with a test key produces sandbox documents. They render and sign exactly like real ones, carry a watermark, email nobody, and count against nothing. Get the iframe sizing right and the completion handler wired while the stakes are zero, then mint a live key and change one environment variable.
The full reference covers publishing, rotating and deleting links, and the guide walks the whole flow. If you use Claude Code, the plugin now ships a template-links skill, so you can describe the page you want and let it write the integration.
Frequently asked questions
How is a template link different from sending a document?
A send needs a name and an email up front. A template link needs neither. You publish one URL, and whoever opens it supplies their own details and signs. Each visit becomes its own document, so ten visitors produce ten separate agreements you can track individually.
Can more than one person sign through a template link?
Yes, but only one role is open to the visitor. Every other signer is named when you create the link, and they are emailed in order once the visitor has signed. That keeps the link from becoming a way for a stranger to nominate your counterparty.
Can I put the link in an iframe?
Not the plain URL, deliberately. It is served with a frame-ancestors policy that refuses framing, which is what stops another site from wrapping your agreement in their own page. Mint an embed URL for the link instead and add your origin to the workspace allowlist.
Can I prefill fields on a template link?
No. Prefill needs to know who is signing, and a link by definition does not. If you already know the signer, send from the template with field_values instead and you get prefill plus a one-call embed link.
How do I stop a link that has leaked?
Rotate it. That issues a new slug and the old URL stops working immediately. You can also set an expiry date or a maximum number of uses when you create it, and delete it outright at any time.
Do links work in the sandbox?
Yes. A link created with a test key produces sandbox documents: watermarked, nobody emailed, nothing counted against your plan. Build the embed against a test link before you publish a real one.
