API-Driven eSignature Templates: A Developer Comparison
Verdocs Team
Your compliance team sends a new consent form for one region, with two extra checkboxes and a different signature block. By the end of the quarter there are six regional versions, three languages, and a rule that the old form must stay live for customers who started under it. The code that sends the forms rarely causes trouble. The trouble comes from keeping the templates behind them correct.
Every eSignature API describes its templates as reusable. That word hides a lot of variation. Some vendors let you define an entire template, including where every field sits, in REST calls. Others let you create the template shell by API but expect a person to place fields in an embedded editor or the web app. Some let you edit a template in place, while others create a new one each time the source document changes. If you maintain many variants, those differences decide how much of the job your code can do.
This article compares one workflow across five platforms, using each vendor's own developer documentation. It covers signing templates only, not document generation products such as Adobe PDF Services Document Generation or DocuSign's document generation features.
The template lifecycle
A reusable signing template goes through four steps:
- Create the template from a PDF or DOCX.
- Author it: define signer roles and place signature and data fields.
- Send from it, prefilling known data for each recipient.
- Maintain it: revise it, or produce a variant when the source form changes.
Each step can happen in one of four places: a direct REST call, text tags embedded in the source document, an embedded editor your users operate on, or the vendor's web app. "API-driven" in a meaningful sense means steps 2 and 4 can happen through the first two, without a person dragging fields around.
The platforms use different names for similar concepts. This terminology map provides a reference for the comparison below; it does not imply identical API resources or feature parity.
| Verdocs | DocuSign | Adobe Acrobat Sign | PandaDoc | Dropbox Sign |
|---|---|---|---|---|
| Envelopes | Envelopes | Agreements | Documents | Signature Requests |
| Templates | Templates; also called server templates | Library Templates (UI); Library Documents (API: libraryDocuments) | Templates | Templates |
| Fields | Tabs (API); Fields (UI) | Form Fields | Fields | Form Fields (form_fields); placement requests use form_fields_per_document |
| Recipients | Recipients, including signers and carbon-copy recipients | Participants / Recipients; Participant Sets and members: participantSetsInfo, memberInfos. CCs are separate. | Recipients (recipients) | Signers and CC recipients: signers, ccs or cc_email_addresses, depending on endpoint |
| Roles | Template Roles / Recipient Roles | Participant slots, such as Participant 1 and Participant 2. The API’s role specifies an action type, such as SIGNER. | Template Roles (roles); assigned through a recipient’s role | Signer Roles and CC Roles (signer_roles, cc_roles) |
| Template Documents | Template Documents (TemplateDocuments) | Documents within a Library Document | No direct equivalent established in the reviewed API docs. Content belongs to the Template. Document Sections are related to assembling files/templates into a transaction. | Documents within a Template (documents); source files supplied as files or file_urls |
Based on official developer documentation reviewed September 25, 2026.
How the five platforms handle it
| Platform | Create | Roles and fields | Ongoing changes |
|---|---|---|---|
| Verdocs | REST: create template, then attach a document | REST roles and fields with page and x/y; text tags and fillable-PDF detection | Update or delete fields by name; duplicate a template |
| DocuSign | REST template create with documents, recipients, and tabs | REST recipients and tabs, by coordinates or anchor strings | REST document replacement and tab updates in place |
| Adobe Acrobat Sign | REST: upload a transient document, then create a library document | Text tags processed on upload, or the authoring view | Form field templates reuse a field layer; library-template field edits shown only in a Postman example |
| PandaDoc | REST create template from a PDF URL or file upload | Field placement in the embedded editor; the upload page says field tags "are not supported yet" | REST PATCH for variables and roles; fields via the embedded editor |
| Dropbox Sign | REST template create | Signer roles and positioned fields in the create call, or an embedded draft | Update files creates a new template and keeps the original; in-place editing through the embedded editor for embedded templates |
What Verdocs' documented paths offer
Verdocs documents a full REST path for every step of the lifecycle, plus two automation shortcuts for teams whose forms already carry structure.
Roles and fields as data. A template role has a name, a type (signer, cc, or approver), and an optional sequence number, and "roles that share the same sequence number act in parallel." A field names its role, document, page, type, and x/y position, with an optional default value. Because fields are addressed by name, field changes can be expressed as code: update or delete the fields that differ. Verdocs also exposes a duplicate-template endpoint; verify the copied resources in your proof of concept before relying on it for variants. The docs recommend creating roles before fields, and field names must be unique within a template.
Text tags for documents you control. If your team authors the source DOCX or PDF, you can embed tags (see the tagging guide) such as {{signature:"Buyer"}}, with options for size, placeholder, and default. When the document is uploaded, the tag pipeline creates the fields. For a regional consent form, that means legal edits the Word file, and your code uploads it without a separate field-mapping step.
Fillable-PDF detection for forms you don't control. Many regulatory and carrier forms arrive as fillable PDFs. Verdocs can "detect native fillable PDF (AcroForm) widgets and map them to signing fields," but only "when no text tags were found on the document." Detected fields initially belong to the template role named Recipient (role_name = "Recipient"); after processing, the sender can reassign them to other roles.
The setup requirement. An organization admin configures field detection through Pipeline Settings, as described in the document-processing guide. A proof of concept should check those settings deliberately and test both automation paths with your real forms.
Sending. An envelope created from a template takes the template ID and a list of recipients, with one recipient matching each template role. Pass those recipient details in the create-envelope request’s recipients array. To prefill known data, supply default values when creating the envelope or update fields before signing begins; signers can still edit them unless a field is marked read-only (FAQ). Signing can then render inside your own app through Verdocs' React components rather than a redirect.
Template changes and sent envelopes. Each new envelope receives its own envelope documents, envelope fields, and recipient records; roles remain tied to the template. Updating a template does not affect envelopes already sent: their documents and fields remain tied to the individual envelope as they were at sending.
Docs your coding assistant can read. Verdocs exposes its developer documentation through an MCP endpoint and Markdown exports, so tools such as Claude or Cursor can search the docs while you build. The same page describes a separate platform MCP for API operations as planned, not yet available.
Where the other platforms are strong
DocuSign’s template API supports replacing documents and updating fields ("tabs") and recipients within an existing template. You can replace a template document, add or update recipients, and update tabs in place, all through REST, and anchor tabs let you place fields relative to text in the document. Envelope creation accepts template roles with tab values, so prefilling data at send time is documented directly.
Adobe Acrobat Sign handles text tags well, and its send flow can merge data into form fields when an agreement is created from a library document. Its form field templates are designed for the "same form, new version" problem: the glossary describes applying the same field layer instead of rebuilding a template each time a document changes. Adobe’s public Postman collection includes a “Change-Fields” example for PUT /api/rest/v6/libraryDocuments/{libraryDocumentId}/formFields, with a JSON fields array containing field definitions and page coordinates. The Postman example provides a useful starting point for evaluating library-template field updates; include this workflow in your proof of concept to confirm it meets your requirements.
Dropbox Sign lets you create a template with signer roles and positioned fields in a single API call, and send with template fills merge fields through custom_fields. The template-create request also exposes ignore_text_tags_extraction_errors, which suggests that text tags are processed during creation, although the documentation does not explicitly confirm that behavior; test it with your source files. When a file changes, update_files overlays the existing fields onto the new file, as long as the new file has the same or more pages and the same orientation. It creates a new template and leaves the original in place, which works for versioning but uses up template quota.
PandaDoc has a strong document-creation API with field prefill. For templates it takes a different approach: the API creates the template and manages roles and variables, while placing fields happens in its embedded editor. The Create Template Editing Session endpoint opens that workflow; as of September 25, 2026, its documentation does not label it beta. That suits products where your customers design their own templates, and it suits pure code-driven maintenance less well.
A proof-of-concept checklist
Documentation shows what is possible. A proof of concept shows whether your forms behave. Test the same workflow on each shortlisted platform with your own documents:
| Test | Why it matters |
|---|---|
| Build one template entirely by API from your real PDF or DOCX | Shows whether field placement can live in code or needs a person |
| Place the same field by coordinates and by text tag | Coordinate systems differ: Verdocs measures y "bottom to top," and DocuSign uses 72 DPI |
| Upload a fillable PDF from a regulator or carrier | Reveals how detected fields are named and assigned to roles |
| Send with prefilled values for two roles | Confirms the send-time prefill path and field naming rules |
| Change one field and one page in the source form | Shows whether you edit in place, duplicate, or create a new template |
| Check what happens to envelopes already in flight | Verdocs isolates sent envelopes from later template edits; verify the behavior on each shortlisted platform |
| Point your coding assistant at the docs | Measures how quickly a developer can find the right endpoint |
Run the checklist before you commit to a vendor. A template that is easy to create but hard to maintain costs you on every regulatory update.
Explore the docs
If your team maintains many signing-template variants and wants field definitions under version control, start with the Verdocs server workflow with static templates tutorial and the document tagging guide. For the architectural side of embedding signing in your own product, see what developers need from an API-first eSignature platform and our guide to embedded eSignature.
