Adobe Acrobat Sign

A test-only simulation of the Acrobat Sign REST v6 agreement workflow. Upload a sample PDF, create an agreement, open its hosted signing URLs and inspect agreement events. Nothing is legally signed, no email is delivered and no request reaches Adobe. Original sample PDFs are returned unchanged; the mock never adds a real signature or certification.

Testlie is not affiliated with, endorsed by or sponsored by Adobe. Adobe and Acrobat Sign are trademarks of their owner, used to identify API compatibility.

#Connect your app

Create Adobe Acrobat Sign under Systems → E-signatures and acknowledge that you will use test data only. Each system has separate credentials, documents, agreements and signing links.

Replace Adobe's API access point with the system's base URL. Keep the /api/rest/v6 prefix:

Send Authorization: Bearer <accessToken> using the access token shown in the system. GET /api/rest/v6/baseUris returns apiAccessPoint and webAccessPoint pointing back to this mock.

The initial test access token acts as an integration key until revoked or rotated. To test token refresh, POST a URL-encoded grant_type=refresh_token, client_id, client_secret and refresh_token to /oauth/v2/refresh. The issued access token expires after 3,600 seconds. POST token to /oauth/v2/revoke to invalidate that token. This does not revoke an entire token family. Clearing the system's stored objects resets the simulated token/revocation state; the normal retention and object limits also apply. Initial OAuth authorization/consent and scope enforcement are outside this simulation; the provided credentials replace that setup.

#Create and sign an agreement

1. POST /api/rest/v6/transientDocuments with a multipart File field containing a sample PDF. The response is { "transientDocumentId": "..." }. Transient documents expire after seven days, or sooner if removed by the plan's retention or object limit.
2. POST /api/rest/v6/agreements with the returned document ID:

{
  "name": "Sample agreement",
  "fileInfos": [{ "transientDocumentId": "<uploaded document ID>" }],
  "participantSetsInfo": [
    { "memberInfos": [{ "email": "first@example.test" }], "order": 1, "role": "SIGNER" },
    { "memberInfos": [{ "email": "second@example.test" }], "order": 2, "role": "SIGNER" }
  ],
  "signatureType": "ESIGN",
  "state": "IN_PROCESS"
}

3. GET /api/rest/v6/agreements/{id}/signingUrls returns signingUrlSetInfos[].signingUrls[], each containing email and esignUrl. Only the current signing order appears; sets with the same order can sign in parallel.
4. Open an esignUrl and choose Sign test agreement, Decline or Leave unsigned. Each completed signer unlocks the next order. Declining cancels the agreement; leaving it unsigned preserves its state. Optional postSignOption.redirectUrl on creation returns the browser to an HTTP(S) URL after its decision.
5. GET /api/rest/v6/agreements/{id} reports OUT_FOR_SIGNATURE, SIGNED or CANCELLED. A signed or cancelled agreement cannot be reopened.

DRAFT and AUTHORING creation states are also supported. PUT /agreements/{id}/state can advance DRAFT → AUTHORING → IN_PROCESS, send a DRAFT directly, or cancel an active agreement with { "state": "CANCELLED", "agreementCancellationInfo": { "comment": "Superseded" } }. There is no form-field authoring UI; supply complete test documents and signers when creating a draft.

#Read documents and activity

All paths below are relative to <base URL>/api/rest/v6:

#Webhook events and scenarios

Configure your receiver URL in the Testlie system's settings. Notifications use Adobe-style event, eventDate, eventResourceType, webhookNotificationId and agreement fields. Supported events are AGREEMENT_CREATED, AGREEMENT_ACTION_REQUESTED, AGREEMENT_ACTION_COMPLETED, AGREEMENT_WORKFLOW_COMPLETED, AGREEMENT_REJECTED and AGREEMENT_RECALLED.

Notifications carry X-ADOBESIGN-CLIENTID, matching the system's application client ID. This public identifier is not a cryptographic signature. The mock's bad signature scenario changes this header so you can test rejecting an unexpected client ID. Delay, drop, duplicate and replay scenarios use the shared delivery machinery.

Webhook registration (/webhooks), Adobe's verification GET request, and its requirement to echo the client ID in each response are not simulated. Delivery results follow Testlie's normal HTTP success/retry rules. Test those Adobe-specific handshake and acknowledgement requirements against Adobe's developer service.

Auto and Require action wait for hosted signing decisions. Succeed immediately completes every test signer when an agreement is sent; Decline cancels it with an AGREEMENT_REJECTED event. Rate-limit, server-error and response-delay scenarios work as for other systems. API processing is immediate; asynchronous PDF conversion/processing states are outside this simulation.

#Compatibility limits

PDF only, at most 1 MB per upload and 1 MB total per agreement, one to five documents and one to 25 SIGNER participant sets with one member each. No remote document fetching, library documents, other participant roles, real email, templates, field editing, certificate signatures, multi-PDF merging or Adobe account administration. Agreement listing covers the newest 1,000 retained agreements. Unsupported operations return explicit errors rather than simulated success.

Documents and agreements follow your plan's retention and object limits; call logs summarize uploaded file content rather than storing a second copy. Use sample PDFs and test identities only.

The wire formats follow Adobe's API usage guide, OAuth guide and agreement events. This is a documented subset, not Adobe certification.