Adobe Acrobat Sign API integration that holds up in production

It depends on who the integration acts for. OAuth suits applications where users act as themselves, or a product used by many Acrobat Sign accounts: each user consents, the application gets an access token valid for an hour plus a refresh token, and scopes limit what it can do. An integration key suits a system-to-system job with no sign-in: it is available on enterprise accounts, carries the permissions of the user who created it, lasts ten years and cannot be edited. For keys we use a dedicated integration user, so access does not depend on one employee's account.

Use webhooks wherever your system can receive them. Adobe recommends them over polling and warns that heavy polling can lead it to temporarily disable API access. Polling remains a documented fallback, for example when the receiving system sits behind a firewall; when we use it, we poll only agreements that are still in progress, back off between calls and stop once the agreement reaches a final state. Webhook endpoints have to answer Adobe's verification request by echoing the application's client ID, and a webhook's URL cannot be changed after it is created, so we put them on a stable address.

Yes. Once an agreement is out for signature, the API returns the signing URL for each participant, and your application can open it in its own flow or on a tablet for in-person signing. A post-sign redirect can return the signer to your application when they finish. For forms the customer starts, the web forms API returns embed code for your site and a hosted URL. One timing detail matters: agreement creation is asynchronous, so a signing URL requested too early can return a 404 that only means processing has not finished.

Acrobat Sign answers with HTTP 429 and a Retry-After value. Limits apply per user and per endpoint, at minute, hour and day levels, and the rate depends on your plan. Since May 2025 Adobe also throttles under high system load, and accounts created after 20 May 2025 are penalised for retrying before the interval ends. We build every call path to wait for the Retry-After interval, back off exponentially and queue work rather than drop it, and we ask Adobe support about higher limits when volumes justify them.

In an org with the Acrobat Sign package, start with the package's global Apex services. AgreementTemplateService creates agreements from admin-maintained templates, EchoSignApiService acts on existing agreements, and the agreements stay on the package's Salesforce objects, with its status updates and data mapping. Calling the REST API directly from Apex means rebuilding much of that yourself. We reserve direct calls for requirements the package does not expose, and say which ones in the architecture review.

Yes. The Acrobat Sign package includes an Apex REST service that loads an agreement template against a Salesforce master record when another system calls it, and returns the new agreement ID or an error. The agreement is then created and tracked in Salesforce like any other. The calling system authenticates to Salesforce, so its access is governed by your Salesforce security model, and we design what it does when the call fails.

Usually, yes. Acrobat Sign supports a separate sandbox environment, which Adobe enables through your customer success manager, and the Salesforce package can be pointed at it by setting the environment name to Sandbox in its environment settings. We build and test there with credentials created for that environment, and promote to production only after the failure paths have passed. If your account has no sandbox, we agree a test approach with you before any code runs against production.