How to Send and Track Employment Documents Across Multiple E-Signature Integrations Using a Unified E-Signature API

April 22, 2026

An e-signature integration lets your product create documents, assign signatories, and track signature status across multiple integrations.

In practice, this is not just a document creation problem.

It is a document state and signer tracking problem.

Each e-signature integration defines:

• document status differently
• signatory roles differently
• signing order differently
• update behavior differently

This guide shows how to build a cross-platform e-signature implementation that:

• retrieves templates
• creates documents
• assigns signatories
• tracks signing progress
• retrieves completed documents

Using the Unified E-Signature API.

Why E-Signature Integrations Break

Most teams start with document creation:

• create a document
• add a signer
• send for signature

This works for one integration.

It breaks when you support multiple:

• status values are inconsistent
• signatory roles differ
• signing order behaves differently
• update behavior varies
• filtering logic becomes inconsistent

The result:

• inconsistent UI
• fragile logic
• increasing maintenance

The issue is not document storage.

The issue is document state + signer tracking.

How the E-Signature Data Model Works

Unified provides a consistent structure across integrations.

• templates define document structure
• documents represent signature requests
• signatories are attached to documents
• document status tracks overall progress
• signatory status tracks individual progress

Step 1: Retrieve Templates

const templates = await sdk.signing.listSigningTemplates({
  connectionId,
});

Each template includes:

• id
• name
• is_active

Step 2: Create a Document

const document = await sdk.signing.createSigningDocument({
  connectionId,
  signingDocument: {
    name: "Offer Letter",
    description: "Please review and sign",
    template_id: templateId,
  },
});

Key points:

• documents can reference a template
• document status is tracked through lifecycle states
• documents include timestamps for sending and completion

Step 3: Add Signatories

await sdk.signing.createSigningSignatory({
  connectionId,
  signingSignatory: {
    document_id: document.id,
    name: "Jane Doe",
    email: "jane@example.com",
    role: "SIGNER",
    order: 1,
  },
});

Important:

• signatories must reference a document
• role determines behavior (SIGNER, APPROVER, CC, etc.)
• order defines intended signing sequence
• multiple signatories can be attached

Step 4: Update Document State

Documents move through lifecycle states:

• DRAFT
• SENT
• DELIVERED
• IN_PROGRESS
• COMPLETED

How a document transitions between states depends on the integration.

const existing = await sdk.signing.getSigningDocument({
  connectionId,
  id: document.id,
});

await sdk.signing.updateSigningDocument({
  connectionId,
  id: document.id,
  signingDocument: {
    ...existing,
    name: "Updated Offer Letter",
  },
});

Important:

• not all fields are writable across integrations
• status transitions may be controlled by the integration
• some actions may not be supported

Step 5: Track Signing Progress

Retrieve document:

const doc = await sdk.signing.getSigningDocument({
  connectionId,
  id: document.id,
});

Retrieve signatories:

const signers = await sdk.signing.listSigningSignatories({
  connectionId,
  document_id: document.id,
});

Filter documents:

const completedDocs = await sdk.signing.listSigningDocuments({
  connectionId,
  status: "COMPLETED",
  updated_gte: "2026-01-01T00:00:00Z",
});

Document status:

• DRAFT
• SENT
• DELIVERED
• IN_PROGRESS
• COMPLETED
• DECLINED
• VOIDED
• EXPIRED

Signatory status:

• PENDING
• SENT
• DELIVERED
• SIGNED
• DECLINED
• ERROR

Use:

• document status → overall progress
• signatory status → individual progress

Step 6: Retrieve the Completed Document

const completed = await sdk.signing.getSigningDocument({
  connectionId,
  id: document.id,
});

Response includes:

• download_url

Integration Differences You Must Handle

All integrations support:

• document
• signatory
• template

Differences still exist:

• document creation behavior may vary
• status transitions are integration-controlled
• sending behavior is not standardized
• signatory roles may not map exactly
• ordering behavior may differ
• not all fields are writable

When unsupported:

• 501 Not Implemented

Do not retry these operations.

Rate Limits and Retry Logic

When rate limits are exceeded:

• 429 Too Many Requests

Recommended approach:

• exponential backoff
• retry only on 429
• avoid retrying validation errors

How the E-Signature Flow Comes Together

The full data flow:

• templates
• → documents
• → signatories
• → document status
• → completed document

This allows you to:

• create documents across integrations
• assign signatories consistently
• track signature progress
• retrieve completed documents

Why Signatory Tracking Is the Hardest Part

Document creation is straightforward.

Signer tracking is not.

Each integration:

• defines roles differently
• supports ordering differently
• handles status transitions differently

Without a unified model, you must:

• map roles per integration
• track signer state manually
• handle edge cases per integration

Unified provides:

• consistent signatory structure
• standard status values
• shared document model

Key Takeaways

• E-signature integrations fail due to document state and signer tracking differences
• Documents track overall signature progress
• Signatories track individual participants
• Templates standardize document creation
• Status tracking requires polling and filtering
• Document updates require read → merge → update
• Signer tracking is the highest-friction part of e-signature integrations

→ Start your 30-day free trial

→ Book a demo