DocuSign CLM API

DocuSign CLM (Contract Lifecycle Management) extends e-sign with repository, workflow, and obligation tracking. Developers search "docusign clm api" when they need programmatic access to contracts beyond envelope send.

What DocuSign CLM offers

DocuSign CLM sits above DocuSign eSignature. Typical capabilities include:

Central contract repository with metadata and full-text search
Workflow stages for legal review, redlines, and approvals before signature
Obligation and renewal tracking after execution
REST APIs and webhooks scoped to CLM objects, not just envelopes

CLM is sold separately from standard eSignature seats. API access requires CLM licensing and admin provisioning.

DocuSign CLM API authentication

CLM REST calls use OAuth bearer tokens scoped to your CLM tenant. Typical setup:

Register an integration key in DocuSign Admin.
Request CLM-specific scopes (document read/write, workflow, search).
Store refresh tokens in a secrets manager. CLM tokens expire faster than long-running batch jobs expect.

Base URLs vary by region and environment. Confirm the hostname in your CLM admin console before hardcoding in CI.

curl -X GET "https://{clm-host}/api/v2/documents/{documentId}" \
  -H "Authorization: Bearer $CLM_ACCESS_TOKEN" \
  -H "Accept: application/json"

Webhook subscriptions for CLM workflow events are configured separately from DocuSign Connect envelope events. Dual-subscribe during migration so status does not fall through the cracks.

CLM endpoint examples

Upload a document to the repository:

curl -X POST "https://{clm-host}/api/v2/documents" \
  -H "Authorization: Bearer $CLM_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "MSA-2026.pdf",
    "documentType": "Agreement",
    "metadata": { "counterparty": "Acme Corp" }
  }'

Start a workflow stage:

curl -X POST "https://{clm-host}/api/v2/workflows/{workflowId}/actions/start" \
  -H "Authorization: Bearer $CLM_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "documentId": "doc-uuid", "assignee": "legal@example.com" }'

Search executed contracts:

curl -X POST "https://{clm-host}/api/v2/search" \
  -H "Authorization: Bearer $CLM_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "query": "renewal_date:[2026-01-01 TO 2026-12-31]" }'

Exact paths depend on your CLM version. Treat vendor OpenAPI specs as source of truth and pin versions in integration tests.

Atlas scope (honest boundary)

Atlas does not replace a full CLM repository. Atlas covers the signing execution layer:

Create envelope from PDF or DOCX
AI-assisted field detection with human confirmation in review
Sequential signing, reminders, void, and post-sign extraction
REST API, webhooks, and MCP for agent workflows

If you need obligation calendars and enterprise contract search, keep CLM or a dedicated CLM vendor. If you need send, status, and signed PDF back in your app, Atlas fits.

Atlas authentication for signing workflows

Atlas does not expose CLM-style repository APIs. Signing automation uses one API key:

curl -X POST https://atlaswork.ai/api/envelope \
  -H "Authorization: Bearer $ATLAS_API_KEY" \
  -H "Idempotency-Key: clm-bridge-001" \
  -H "Content-Type: application/json" \
  -d '{ "document_url": "https://cdn.example.com/export.pdf" }'

Optional webhook_url on create replaces CLM status polling for the signature leg. Verify X-Atlas-Signature on inbound hooks. See Webhook debugging.

Post-sign structured data is available via the contract.extracted webhook or MCP extract_contract_data. Push extracted fields into your CLM metadata if you keep CLM as system of record.

Mapping common CLM tasks

CLM intent	DocuSign CLM API area	Atlas equivalent
Upload draft contract	Documents API in CLM	POST /api/envelope (PDF or DOCX)
Route for internal approval	CLM workflow stages	Review URL before POST /api/envelope/{id}/send
Send for signature	CLM + eSignature bridge	POST /api/envelope/{id}/send
Track signature status	CLM status + Connect	GET /api/envelope/{id}/status or webhooks
Store signed PDF	CLM repository	GET signed PDF via API or webhook payload
Extract key fields post-sign	CLM metadata	contract.extracted webhook + extract_contract_data (MCP)

Migration notes

Teams leaving CLM for a lighter stack usually keep CLM for legacy storage and route new sends through Atlas:

Export executed PDFs you still need for search (CLM export tools).
Point new automations at POST /api/envelope instead of CLM document create.
Map Connect events to Atlas webhook handlers (envelope.sent, envelope.signed, etc.).
Run dual-write on one template until webhook parity is verified.

Do not delete CLM retention policies until legal signs off on archive location.

Atlas create example

curl -X POST https://atlaswork.ai/api/envelope \
  -H "Authorization: Bearer $ATLAS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_url": "https://example.com/msa.pdf",
    "webhook_url": "https://your-app.com/hooks/atlas",
    "parties": [
      { "email": "vendor@example.com", "name": "Vendor Rep", "role": "Vendor" }
    ]
  }'

Response:

{
  "envelope_id": "uuid",
  "review_url": "https://atlaswork.ai/review/uuid?rt=..."
}

Open review_url, confirm fields, then send:

curl -X POST "https://atlaswork.ai/api/envelope/$ENVELOPE_ID/send" \
  -H "Authorization: Bearer $ATLAS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"parties":[{"email":"vendor@example.com","name":"Vendor Rep","role":"Vendor"}]}'

When to stay on DocuSign CLM

Legal mandates a single contract system of record with obligation management.
You already built CLM workflow stages non-technical users rely on daily.
Procurement renewed CLM in the last quarter and migration cost is prohibitive.

CLM API scope FAQ

Does CLM include eSignature API access? CLM licensing is separate from eSignature seats in most enterprise quotes. Confirm both SKUs appear in your order form.

Can Atlas store obligation metadata? Use metadata.client_reference_id and webhooks to push data to your CLM or ERP. Atlas is not a contract repository.

What about redlines before sign? CLM workflow stages handle redlines. Atlas review page handles field and party confirmation before send, not multi-version redline merge.

How do auditors view split systems? Document which system holds executed PDFs of record. Splitting CLM storage and Atlas signing is common if legal approves archive routing.

Who owns template versioning? CLM owns version trees. Atlas templates cover repeat send shapes after you finalize field layout in review once.

Can I trigger Atlas from a CLM workflow webhook? Yes. On CLM stage "Ready for signature", POST to Atlas create with the exported PDF URL and write envelope_id back to CLM metadata.

Dual-write risk? Running CLM eSignature bridge and Atlas in parallel can double-send. Pick one signing rail per document type during migration.

CLM API rate limits? Batch search and export jobs need pagination. Mirror the same pattern when polling GET /api/envelopes on the Atlas side.

MCP for agents? Atlas MCP tools cover create, send, status, and extract. Useful when legal ops wants ChatGPT or Claude to kick off signing without opening CLM UI.