DocuSign (platform)

DocuSign eSignature is the execution and evidence layer for a decision. composerID publishes an Intent as a signature Envelope, embeds the Intent ID as an envelope custom field, and tracks completion through DocuSign Connect. It is the signature step in an SoW or contingent-contract chain, not the system of record for the work itself.

API at a glance Minimum viable mapping Custom fields & tenant mapping

Publish path

Direct API

composerID adapter → DocuSign API

Events back

Push events

native webhooks / events back

API access

Open docs

public developer portal

Contract tier

Tier A

full loop: publish + events back

Tenant configuration (mandatory fields, approval chains, picklists) is a separate gate from vendor capability: it is discovered at preflight before first publish and may need destination admin changes. How composerID connects →

Reference

API at a glance

The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.

Authentication	OAuth 2.0 - JWT Grant for service integrations (no user login) or Authorization Code Grant; request the signature scope. Auth host account.docusign.com (account-d.docusign.com demo); token at POST /oauth/token; call /oauth/userinfo once to resolve the account base_uri.
API style	REST, JSON; Authorization: Bearer
Base URL	https://{account-base-uri}.docusign.net/restapi/v2.1/accounts/{accountId}
Objects	envelopes, documents, recipients (signers), tabs, templates, textCustomFields, Connect configurations
Events / webhooks	DocuSign Connect - push notifications on envelope and recipient status (sent, delivered, completed, declined, voided).
Rate limits	Hourly per-account request ceilings with burst allowance; 429 with backoff. /oauth/userinfo is separately rate-limited, so cache the base_uri.

Developer access

The DocuSign API details are for registered developers

Auth model, base URLs, event posture and rate limits, free with a developer account.

Get free access → Registered developers are recognised automatically.

Readiness

Docs confidence: Public

“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.

Deterministic mapping

Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).

Tenant discovery

composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.

Enrichment loop

If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.

Mapping

Minimum viable mapping for DocuSign

An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.

Object	Canonical fields	Platform target	Required status	Notes
Envelope Create signature request from the decision	defence_file (document), signers = approvers/business_owner, emailSubject = intent.title	POST /restapi/v2.1/accounts/{acct}/envelopes	Required	status=sent to dispatch; documents supplied as base64
Intent ID correlation Write the Intent ID onto the envelope	intent_id, intent_version	Envelope textCustomFields	Required	Level-1 correlation - Intent ID recoverable from any completed envelope
Completion back-sync Read for the intent timeline	envelope status, completedDateTime, signers[]	Connect webhook / GET /envelopes/{id}	Recommended	Store the completed PDF plus the certificate of completion

Developer access

The field-level mapping is for registered developers

Object targets, canonical fields and the Intent ID carrier for DocuSign, free with a developer account.

Get free access → Registered developers are recognised automatically.

Idempotency & drift: publish + reconcileExpand

Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.

Tenant specifics

Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)

Important: where this platform is tenant-definedExpand

eSignature is the signature/execution step, not the system of record for the underlying work - pair it with the VMS/CLM/S2P destination that owns the engagement. DocuSign now markets the broader IAM platform; composerID targets the stable eSignature REST API. Production and demo use different base hosts, so always resolve the per-account base_uri via /oauth/userinfo.

Developer access

Tenant-mapping notes are for registered developers

Where DocuSign deployments differ tenant to tenant, and what to check before first publish.

Get free access → Registered developers are recognised automatically.

Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.

Back to Platforms How integrations work API reference