Packaged add-ins cover M365 and Salesforce well. Proprietary portals need the Acrobat Sign REST API to create agreements, place recipients, and react to status changes.
Authentication (OAuth 2.0)
API calls require OAuth access tokens with scopes such as agreement write and widget read (exact scope names depend on your API application). Register an API application in the Sign admin console and store secrets in a vault — never in front-end code.
POST /oauth/v2/token Content-Type: application/x-www-form-urlencoded client_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET &grant_type=authorization_code &code=AUTHORIZATION_CODE &redirect_uri=YOUR_REDIRECT_URI
Core developer pipeline
1. Upload a transient document
POST /api/v6/transientDocuments
Authorization: Bearer ACCESS_TOKEN
Content-Type: multipart/form-data
→ { "transientDocumentId": "..." }
2. Create and send the agreement
POST /api/v6/agreements
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
{
"fileInfos": [{ "transientDocumentId": "YOUR_TRANSIENT_ID" }],
"name": "Enterprise Service Agreement",
"participantSetsInfo": [{
"memberInfos": [{ "email": "[email protected]" }],
"order": 1,
"role": "SIGNER"
}],
"signatureType": "ESIGN",
"state": "IN_PROCESS"
}
Field names and envelope structure follow the current Adobe Sign API documentation for your shard — always verify against the official API reference for your account’s base URI.
3. Prefer webhooks over polling
Register a webhook endpoint so Acrobat Sign notifies your service on status changes (completed, cancelled, expired). That avoids hammering the API and keeps CRM/ERP indexes fresh.
Related: Acrobat Services API (PDF factory) · Power Automate.
Code samples are illustrative. Confirm endpoints, payloads, and scopes in Adobe’s current developer documentation before production use.