Unified E-Signature API

What Is a Unified E-Signature API?

A unified e-signature API is a single, standardized programming interface that lets your product send documents for signing, track signer progress, and retrieve signed files across multiple e-signature platforms without building a separate integration for each one.

Most products only ever need to integrate with one e-signature vendor, which is why this category looks different from HRIS, CRM, or accounting: there's no established multi-vendor aggregator market the way there is in those verticals. Where a unified API earns its keep here is when a product needs to support more than one signing standard at once, most commonly global e-signature (DocuSign, Adobe Acrobat Sign) alongside India-specific compliance signing (Aadhaar eSign, Digital Signature Certificates through Digio, Emudhra, or Leegality). Knit's signType field supports AADHAR, DSC, ELECTRONIC, and WRITTEN as first-class values, not an afterthought bolted onto a global-only schema.

Knit normalizes three things across all providers:

How It Works

1. Your customer connects their e-signature platform
Knit's pre-built embedded auth UI handles OAuth and token management per provider. Your team writes zero auth code.

2. Knit normalizes the request
Signers, signature type, document placement, and verification rules are mapped to Knit's unified schema, regardless of how each platform structures its own signing request.

3. Your product calls one API
Send a document, generate signer URLs, send reminders, and download the signed file through the same set of endpoints no matter which platform is connected.

4. Stay in sync with real-time webhooks
Native and virtual webhooks fire on signing events, so your product can track a document's progress without polling.

E-Signature Data Objects

The following objects are available through the unified schema. All fields are normalized across providers.

Signing Requests

A document sent for signature, with one or more signers, their signature type, and where their signature should appear on the page.

signers[]: {
  name, emailId, phone,
  signType: AADHAR | DSC | ELECTRONIC | WRITTEN,
  comment,
  signCoordinates[]: { page, llx, lly, urx, ury },
  signatureVerification: {
    maxAttempt,
    conditions[]: { field, matchType: FUZZY | EXACT, value, threshold }
  }
},
documentName, document, contentType,
senderName, senderEmailId, notifyForSigning,
referenceNum, redirectURL, webhookURL, metaData

document is base64-encoded. signCoordinates uses PDF coordinate space to place a signature block on a specific page. signatureVerification supports identity-matching conditions, which matter for Aadhaar and DSC signing, where India's compliance requirements call for signer identity verification beyond a signature capture.

→ Send document for signing

Sign URLs

The per-signer URL used to redirect each signer to the actual signing interface.

signers[]: { email, signUrl }

Returned both in the initial Send Document response (as signers[].signUrl) and retrievable separately by documentSignId.

→ Get sign URLs

Documents

The signed or in-progress document file itself.

document (base64-encoded)

→ Download document

Reminders

A notification sent to signers who haven't completed signing yet.

documentSignId

→ Send reminder for signing

API Reference

All e-signature endpoints are organized by category. Each endpoint works identically regardless of the underlying platform. Pass your API key and the customer's X-Integration-Id, and the response schema is consistent across all providers.

Signing APIs

Document APIs

Supported Platforms

Knit connects to five e-signature platforms, spanning both global and India-specific compliance signing.

Don't see a platform? Use the Connector Builder / Integration Agent to add it yourself in hours, not weeks.

Key Capabilities

Real-Time Sync & Webhooks

Knit supports both native webhooks (forwarded directly from platforms that emit them) and virtual webhooks (Knit polls the source, detects changes, and emits events). Both use the same subscription interface and event schema, so your integration code is identical either way.

Aadhaar and DSC Signing Support

signType treats AADHAR (Aadhaar-based eSign) and DSC (Digital Signature Certificate) as first-class signing methods alongside ELECTRONIC and WRITTEN, with signer identity verification conditions built into the same request. Most global e-signature APIs have no equivalent, since these are India-specific regulatory signing standards.

Zero Data Storage

Knit never stores your customers' documents at rest. Every API request passes through to the source e-signature platform in real time. This reduces your GDPR, CCPA, DPDP, and SOC 2 compliance scope, since there are no replicated documents sitting in a third-party system.

Precise Signature Placement

signCoordinates lets you position a signature block on a specific page and location using PDF coordinate space, normalized the same way regardless of which platform ultimately renders the signing interface.

AI Connector Builder / Integration Agent

When a customer's e-signature platform isn't in Knit's library, the AI Connector Builder lets your team define a new connector in hours. Specify the platform's API structure and data mapping; Knit's AI generates the connector.

Passthrough API

Need a field outside the unified request format, like a DocuSign-specific envelope setting or an Adobe Sign workflow rule? Passthrough lets you make direct calls to the underlying platform using Knit's authentication layer.

MCP Compatibility

Knit is MCP-compatible, giving AI agents authenticated access to send documents, check signing status, and retrieve signed files across every connected platform through the same unified layer, with no per-provider auth or endpoint logic in your agent code.

Quick Start

Authentication

All requests require two headers:

Authorization: Bearer YOUR_API_KEY
X-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID

The X-Integration-Id is the unique identifier for a specific customer's connected e-signature platform, issued after they complete the Knit auth flow.

Send a document for signing

curl --request POST \
     --url https://api.getknit.dev/v1.0/sign.document.send \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID' \
     --data '
{
  "documentName": "Employment Agreement",
  "document": "BASE64_ENCODED_PDF_CONTENT",
  "contentType": "application/pdf",
  "signers": [
    {
      "name": "Jordan Lee",
      "emailId": "[email protected]",
      "signType": "ELECTRONIC"
    }
  ],
  "senderName": "Acme HR",
  "senderEmailId": "[email protected]",
  "notifyForSigning": true
}'

Response: same schema whether the customer uses DocuSign, Adobe Sign, or Digio:

{
  "documentSignId": "uniqueSignId",
  "redirectionSupported": true,
  "signers": [
    {
      "name": "Jordan Lee",
      "emailId": "[email protected]",
      "signUrl": "https://provider.example.com/sign/xxxx"
    }
  ]
}

Send an Aadhaar eSign request

curl --request POST \
     --url https://api.getknit.dev/v1.0/sign.document.send \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID' \
     --data '
{
  "documentName": "Loan Agreement",
  "document": "BASE64_ENCODED_PDF_CONTENT",
  "contentType": "application/pdf",
  "signers": [
    {
      "name": "Priya Sharma",
      "emailId": "[email protected]",
      "phone": "+919000000000",
      "signType": "AADHAR",
      "signCoordinates": [{ "page": 1, "llx": 100, "lly": 100, "urx": 200, "ury": 150 }]
    }
  ]
}'

Download the signed document

curl --request GET \
     --url 'https://api.getknit.dev/v1.0/sign.document.download?documentSignId=uniqueSignId' \
     --header 'accept: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Use Cases

Multi-Region Compliance Signing

For products serving both global and Indian customers, route signing requests to the right compliance standard automatically, DocuSign or Adobe Sign for global customers, Aadhaar eSign or DSC for India, through the same API call shape.

Typical flow: detect customer region or regulatory requirement → set signType accordingly → send document → track completion via webhook

Embedded Contract Signing

Let users complete a signing flow without leaving your product, using the per-signer signUrl returned from the send-document call.

Typical flow: send document → embed or redirect to signUrl → webhook on completion → download the signed document for storage

HR & Onboarding Document Automation

Combine the Unified E-Signature API with Knit's Unified HRIS API to send offer letters or policy acknowledgments for signature as part of an onboarding workflow.

Typical flow: new hire created in HRIS → generate offer letter → send for signing → webhook on completion → attach signed document to the employee record

Lending & Financial Document Signing

For fintech products operating in India, use Aadhaar-based signing to meet regulatory requirements for loan agreements and KYC documents alongside standard electronic signatures for other markets.

Typical flow: generate loan agreement → send with signType: AADHAR and identity verification conditions → confirm signer identity match → download the executed agreement

Automated Reminders & Completion Tracking

Reduce document turnaround time by automatically reminding signers who haven't completed a pending document, without building per-provider reminder logic.

Typical flow: send document → poll or schedule check → send reminder to pending signers → webhook on final completion

FAQ

What is a unified e-signature API?
A unified e-signature API is a single, standardized interface that lets your product send documents for signing and manage signer workflows across multiple e-signature platforms without building a separate integration for each one.

Why would I need a unified API for e-signature, if most products only use one vendor?
If your product only ever needs one e-signature vendor, a unified API may not be necessary. The clearest case for it is supporting more than one signing standard at once, most commonly global e-signature (DocuSign, Adobe Sign) alongside India-specific compliance signing (Aadhaar eSign, Digital Signature Certificates), which Knit's signType field supports natively.

What is Aadhaar eSign and DSC signing?
Aadhaar eSign lets an individual sign a document using India's Aadhaar identity system for legally recognized electronic signatures. DSC (Digital Signature Certificate) is a certificate-based digital signature standard used for regulatory and compliance signing in India. Both are supported as signType values alongside standard ELECTRONIC and WRITTEN signatures.

How long does it take to integrate?
Most teams go live in 1–3 days with Knit. Building a production-ready 1:1 native integration against a single platform like DocuSign typically takes several weeks. When you build with Knit, one integration gives you access to every connected e-signature platform, and Knit maintains all connectors as providers update their APIs.

Does Knit store signed documents?
No. Knit is a pass-through layer: requests hit the source e-signature platform in real time and no document content is stored at rest. This reduces your GDPR, CCPA, DPDP, and SOC 2 compliance scope.

What if a customer's e-signature platform isn't on the list?
Using the Connector Builder, we can add a new connector in hours.

Is Knit compatible with AI agents and MCP?
Yes. Knit is MCP-compatible, so agents in MCP-compatible frameworks can perform authenticated e-signature actions via Knit with no per-provider logic.

What's the passthrough API?
The passthrough API lets you make direct calls to the underlying e-signature platform using Knit's authentication layer. Use it for fields outside the unified schema.

Next Steps