Salesforce e-sign API

---

title: Salesforce e-sign API

description: Production Salesforce e-sign API on Atlas: idempotent creates, party tokens on sign URLs, and email delivery-backed signer email.

date: 2026-06-11

updated: 2026-06-11

---

"salesforce e-sign api" searches come from RevOps and engineering teams wiring Opportunity stages to signed PDF artifacts. Salesforce ships native e-sign with supported vendors. Atlas exposes REST plus webhooks when you need headless control outside marketplace apps.

Share: Opportunity stage triggers create. Signed PDF closes the loop.

Salesforce native options

Salesforce offers e-sign through AppExchange integrations with DocuSign, Adobe, and others. Flow and Apex can trigger envelope creation when Opportunity stage changes. Signed documents attach to records with timeline visibility for sales reps.

Native paths fit orgs that approved a marketplace connector and trained reps inside Salesforce UI.

Atlas + Salesforce pattern

Atlas does not ship a Salesforce managed package today. Supported architecture:

Opportunity stage change (Flow or Platform Event)
 → Apex REST callout or middleware
 → POST /api/envelope (PDF or DOCX)
 → review_url stored on custom field
 → Human Send or template auto_send
 → Atlas webhook → Apex updates Opportunity + ContentVersion

See e-sign Salesforce for complementary CRM notes.

Apex callout example (middleware preferred)

Salesforce callouts should land on your middleware, not embed Atlas API keys in Apex when avoidable. Middleware holds secrets and verifies webhooks.

curl -X POST https://atlaswork.ai/api/envelope \
 -H "Authorization: Bearer $ATLAS_API_KEY" \
 -H "Content-Type: application/json" \
 -H "Idempotency-Key: sf-opp-006xx-create" \
 -d '{
 "document_url": "https://example.com/order.pdf",
 "webhook_url": "https://middleware.example/webhooks/atlas",
 "metadata": {
 "client_reference_id": "opp-006XX000004",
 "external_id": "006XX000004"
 },
 "parties": [{"email": "buyer@example.com", "name": "Buyer", "role": "Customer"}]
 }'

Store envelope_id on Opportunity.Atlas_Envelope_Id__c before you expose review_url to sales.

Webhook handler back to Salesforce

Verify X-Atlas-Signature HMAC on every POST. On envelope.signed:

Download signed PDF from GET /api/envelope/{id}
Insert ContentVersion linked to Opportunity
Update stage to Closed Won or custom Signed stage
Log Platform Event for downstream analytics

Idempotency key: envelope_id + event type.

DocuSign Salesforce API vs Atlas

DocuSign Salesforce connector wins when legal standardized globally and AppExchange package passed security review. Deep admin tooling and signer brand recognition remain strengths.

Atlas wins when sends originate from custom product portals, agents in Claude via MCP, or middleware you control. Usage pricing at $1 per envelope after five free sends avoids per-seat tax on integration-only identities.

DocuSign comparison for incumbent detail.

Template send for repeat Salesforce SKUs

Standard order forms should use POST /api/templates/{id}/send with prefill from Opportunity fields:

{
 "parties": [{"email": "buyer@example.com", "name": "Buyer", "role": "Customer"}],
 "prefill": {"amount": "75000", "sku": "Enterprise"}
}

Call get_template via MCP or GET template docs before send to match role names.

Implementation depth for "salesforce e-sign api"

Production signing integrations fail on edge cases, not happy-path demos. Below is a checklist teams wish they had before the first production send.

Create path hardening

Always pass Idempotency-Key derived from Opportunity Id plus document hash. Flow retries must not duplicate envelopes.

Upload PDF or DOCX via multipart when bytes live on disk. Use document_url when files live in Salesforce Files with a signed URL your middleware fetches.

Poll fields_status before send on ad-hoc creates.

Review gate semantics

Atlas defaults to review-first on ad-hoc creates. Sales ops opens review_url from Opportunity field before customer email dispatches.

Templates can auto-send when legal trusts the SKU order form.

Webhook verification

Verify HMAC before any Opportunity stage mutation.

Handle at least: envelope.sent, envelope.signed, envelope.voided, and envelope.declined.

Sequential signing rules

Atlas signs in order. Multi-party Opportunities need per-party tokens in sign URLs.

Governor limits and callouts

Batch Apex should enqueue middleware jobs rather than synchronous callouts on bulk stage changes.

Log envelope_id in Custom Object for support when callouts fail mid-flight.

Security review talking points

API keys stay on middleware or Named Credentials, not in Flow formulas visible to all admins.

Webhook HMAC uses your Atlas API key as secret. Reject bad signatures before CRM writes.

Pilot success metrics

Time from Opportunity trigger to signed ContentVersion attached.

Webhook latency p95 under load.

Support tickets per hundred Salesforce-triggered sends.

Five free sends at /signup validate salesforce e-sign api before paid credits.

Additional salesforce e-sign api context

Salesforce teams often store DocuSign envelope IDs in custom fields today. Mirror that pattern with Atlas_Envelope_Id__c before you cut over Flow automation.

Platform Events give downstream analytics a clean stream when Opportunity stage changes from webhook handlers without blocking Apex limits.

Compare MCP electronic signatures when sellers also send from Claude alongside Salesforce-triggered flows.

Run create, review, send, webhook, ContentVersion upload in full sandbox before production middleware deploy.

FAQ

Does Atlas replace DocuSign for Salesforce? Only when your documents are PDF or DOCX from your product and usage-priced API sends beat seat quotes. Enterprise DocuSign footprints often stay on legacy flows.

Can Flow call Atlas directly? Prefer middleware for secrets. Flow can POST to your server which calls Atlas.

Credits? One per envelope sent. Drafts free.