GuidesAPIMCP

Acrobat Sign API

---

title: Acrobat Sign API

description: Production Acrobat Sign API on Atlas: idempotent creates, party tokens on sign URLs, and email delivery-backed signer email. Includes five free sends on signup.

date: 2026-06-11

updated: 2026-06-11

---

"acrobat sign api" sits at the intersection of product shipping and compliance. Atlas keeps the surface small: create, review, send, webhook, download.

> Share: One POST to create, one review click, one webhook when signed.

Searchers type "acrobat sign api" when they mean Adobe Acrobat Sign's REST surface but use Acrobat product naming. Adobe rebranded HelloSign-adjacent flows under Acrobat Sign inside Document Cloud. This guide clarifies naming and maps API patterns to Atlas.

Acrobat Sign vs Adobe Sign naming

Adobe marketing uses:

  • Adobe Acrobat Sign in enterprise and Document Cloud contexts
  • Acrobat Sign in shorter product copy and search results
  • Legacy Adobe Sign in older API docs and SDK packages

For developers, all three usually resolve to the same REST API base URLs and OAuth integration keys in Adobe Admin Console.

API entry points

Acrobat Sign REST lives under regional hosts such as:

  • https://api.na1.adobesign.com/api/rest/v6/
  • EU and other shards use different host prefixes

Core resources include:

  • transientDocuments (upload bytes)
  • agreements (envelope equivalent)
  • libraryDocuments (templates)
  • webhooks (account event subscriptions)

Authentication uses OAuth bearer tokens or JWT service accounts. See Adobe Sign REST API for endpoint detail.

Typical integration flow

  1. Upload PDF to transientDocuments
  2. Create agreement with participant sets and signature type
  3. Move agreement to IN_PROCESS
  4. Signers complete in Acrobat-branded UI
  5. Download combined PDF via agreements/{id}/documents

Atlas equivalent:

  1. POST /api/envelope with PDF or DOCX
  2. Open review_url, confirm detected fields
  3. POST /api/envelope/{id}/send
  4. Signers use atlaswork.ai/sign links
  5. GET signed PDF via API or webhook payload

Acrobat-centric assumptions

Acrobat Sign APIs assume:

  • Admin Console user provisioning
  • Signers may open documents inside Acrobat Reader workflows
  • Library documents mirror Acrobat template authoring

Atlas assumes:

  • Documents arrive from your app, URL, or agent
  • Field detection proposes placement; review confirms
  • Agents can use MCP instead of hand-built REST wrappers

When Acrobat Sign API fits

  • Organization already pays for Document Cloud seats
  • Legal expects Adobe-branded signer experience
  • Templates were authored in Acrobat and must stay there short term

When Atlas fits instead

  • Sends originate from Claude, Cursor, or backend automation
  • You want usage-priced sends without Acrobat seat bundles
  • Review-before-send should default on ad-hoc documents

Compare Adobe Acrobat Sign alternative for buyer-level comparison.

Migration checklist

  • Export library document IDs and field names from Acrobat
  • Map agreement status enum to your internal state machine
  • Rewrite webhook verification (Adobe vs Atlas HMAC schemes)
  • Run dual-write on one template until signed PDF retention passes legal review

Further reading

Acrobat Sign API FAQ

Is Acrobat Sign API different from Adobe Sign API? Same product family. Hostnames and docs may say adobesign.com regardless of marketing name.

Can Atlas ingest Acrobat-exported PDFs? Yes. POST /api/envelope accepts PDF uploads and document_url fetches.

Embedded in Acrobat? Acrobat Sign embedded flows use Adobe-hosted components. Atlas uses sign URLs with party tokens from your portal.

MCP support? Acrobat Sign has no native MCP. Atlas ships ten MCP tools for agent clients.

DOCX support? Atlas accepts DOCX on create and converts for signing. Acrobat Sign workflows typically expect PDF uploads.

Regional API shards

Adobe partitions API hosts by region. Using the wrong shard breaks authentication and may violate data residency commitments.

Document which shard your Admin Console assigned. Staging and production should match region policy.

SDK vs raw REST

Adobe ships SDKs for common languages. SDKs still wrap the same REST v6 resources documented above.

Atlas documents OpenAPI and llms.txt for agent clients. curl-first integration is the happy path.

Library document migration

If templates live in Acrobat library documents, export field names and participant roles before migration.

Atlas templates save from a successful envelope send in dashboard or via template API. Field ids are stable UUIDs on Atlas fields array.

Signer authentication options

Adobe supports multiple authentication levels on agreements. Match your compliance requirements before build.

Atlas uses email links with party tokens for standard flows. Confirm advanced auth needs with legal during pilot.

Monitoring and support

Track agreement completion rate and time-to-sign in your analytics warehouse. Slow completion may indicate signer UX issues, not API bugs.

Adobe enterprise support tiers vary. Atlas support uses in-app chat and docs for product issues.

Dual-run checklist

  1. Pick one document type
  2. Send via Adobe and Atlas to test inboxes
  3. Compare signed PDF byte size and audit metadata
  4. Verify webhook delivery latency
  5. Get legal sign-off on artifact shape before cutover

Acrobat desktop version skew

Signers on mixed Acrobat versions may see slightly different field rendering. Test on oldest supported Reader version your clients use.

Atlas sign page is web-based so browser matrix matters more than desktop Acrobat version.

Schedule quarterly regression on Safari and Chrome mobile for signer completion flows.

FAQ

Does Atlas accept PDF and DOCX?

Yes on every create path.

How do I authenticate?

Bearer API key from dashboard settings.

When do credits get used?

One credit per send, not per upload.

Where is the full API reference?

e-signature API and /openapi.json.