Adobe Acrobat Sign Automation

Verify Acrobat Sign webhooks with X-ADOBESIGN-CLIENTID echo, a five-second ACK, and retrieval after complete.

2026-09-09 — Craig Major

You can register an Acrobat Sign webhook only after an HTTPS GET carries X-ADOBESIGN-CLIENTID and your listener returns 2XX with the same Application ID echoed back. Every later notify POST needs the same echo. Queue PDF and store work before the documented five-second validation timeout. The published E-Signature Automation guide owns the shared Signing Control Plane. This page is the Acrobat Sign adapter: agreement.id, webhookNotificationId, resource-level webhooks, and retrieval after complete. The Adobe Sign Webhook Verification Pack gives you fiction fixtures for those checks.

Start from the Signing Workflow Requirements Workbook if you still need the shared field list. If you already verify DocuSign Connect, keep the published DocuSign E-Signature Automation page for that HMAC. If you already acknowledge Dropbox Sign callbacks, keep the published Dropbox Sign E-Signature Automation page for that event_hash. Those checks are not interchangeable. If the missing job is a named approve, reject, or request-changes decision, use the published Document Approval Workflow. An Adobe APPROVER participant role is not that decision.

Who this is for

Use this when agreements already go out through Adobe Acrobat Sign and the missing piece is a verified webhook listener. You need a named sender, one document family, and a place to keep SignatureEvidence. Confirm an HTTPS webhook URL on port 443 or 8443, an Application ID, and the OAuth webhook scopes you can actually request before you promise a listener to a team.

You do not need this page if you are still choosing a first workflow. Start with Document Processing Automation. You also do not need it if the job is an internal approve, reject, or request-changes decision. That job stays on the published Document Approval page.

The download includes:

• CLIENTID echo tests for intent GET and notify POST
• Header echo and JSON xAdobeSignClientId body echo
• Five-second ACK with queued work
• The 45-second callback timeout as a separate setting
• webhookNotificationId replay cases
• RESOURCE versus ACCOUNT scope
• 72-hour disablement and lost-notification notes
• Retrieval after complete versus 10 MB truncation
• SX01 through SX12 plus SX-ADB-01 through SX-ADB-06
• A forbidden-downstream sheet

Canadian Keyword Planner reports brand search for Adobe Acrobat Sign as navigational. It does not prove workflow demand. Automation phrases for Adobe Acrobat Sign workflow, document, contract, approval, generation, and template sit outside reported volume. This page survives on webhook depth, not invented demand. Adobe Acrobat Sign alternatives is 10-100 and stays in a later FAQ. DocuSign vs Adobe Sign is 100-1K and is a later comparison, not this title. Adobe Sign is a FAQ alias, not a second title.

What this adapter owns

The hub already defined send, remind, void, decline, complete, and download. It already named SignatureEvidence. It already blocked payment, bank-detail change, final accounting, auto-renew, and auto-terminate.

This page adds the Acrobat Sign surfaces:

• agreement.id as signature_request_id
• webhookNotificationId as event_id
• Intent GET plus notify POST CLIENTID echo
• HTTPS 2XX as the delivery ACK
• WEBHOOK_REQUEST_TIMEOUT_VALIDATION at 5 seconds
• CALLBACK_REQUEST_TIMEOUT at 45 seconds
• ACCOUNT, GROUP, USER, and RESOURCE scope
• AGREEMENT_WORKFLOW_COMPLETED or Agreement Status Complete as the retrieval signal

Do not clone the hub and swap the product name. Do not reuse the DocuSign raw-body Base64 check. Do not reuse the Dropbox Sign Hello API Event Received string or multipart json parse. If a field is shared, keep the hub name. If a field is Acrobat Sign-only, say so.

Intent GET

Official Webhooks in Acrobat Sign guidance, accessed 9 September 2026, is specific:

1. Your app calls POST /webhooks with an OAuth token and an HTTPS webhook URL.
2. Acrobat Sign sends an HTTPS GET to that URL with request header X-ADOBESIGN-CLIENTID.
3. The header value is the Application ID that is trying to register the webhook.
4. Your listener must return an HTTPS 2XX response.
5. The same Application ID must come back either in response header X-ADOBESIGN-CLIENTID / X-AdobeSign-ClientId or in a JSON body key xAdobeSignClientId.
6. If that check fails, the webhook is not created.

The same GET runs when an inactive webhook is moved back to ACTIVE. A failed echo leaves the webhook inactive.

Unknown Application IDs must not return success. Official guidance says a listener can whitelist the apps it accepts. Echoing every CLIENTID you see is how a wrong URL gets registered.

Official sample snippets use placeholder Application IDs. This page and the test pack use fiction IDs only. Confirm the Application ID on your Acrobat Sign API page.

Notify POST

Notification POSTs are application/json. Official payload overview, accessed the same day, says Acrobat Sign sends the payload object to every webhook URL you defined.

Every notify request also carries X-ADOBESIGN-CLIENTID. Official events guide: delivery counts only when you return 2XX and echo the same client ID in the header or in xAdobeSignClientId. An empty 200 is not enough. A 204 without the echo is not enough. If the echo is missing, Acrobat Sign retries until the retry budget is exhausted.

That is not a Dropbox Sign callback. Dropbox Sign wants HTTP 200 and the exact body Hello API Event Received. It is also not DocuSign Connect. DocuSign HMAC covers the raw POST body and then Base64-encodes the digest. Do not bring those habits here.

Five seconds, then 45 seconds

Official events guide names two timeouts:

• WEBHOOK_REQUEST_TIMEOUT_VALIDATION: 5 seconds
• CALLBACK_REQUEST_TIMEOUT: 45 seconds

The five-second figure is the one that governs webhook ACK. Official best practice: respond quickly, then process and store signed documents on another thread or a queue. If you download a PDF inside the request, you will miss the window.

The 45-second figure is a separate callback setting. Do not treat 5 and 45 as one number. Do not invent a third timeout.

ACK is not the SignatureEvidence write. Return 2XX plus the CLIENTID echo. Queue verification, storage, and download.

webhookNotificationId

Official payload overview: webhookNotificationId is the unique identifier of the webhook notification. Use it to spot duplicates.

Official events guide adds a second reason you will see the same work twice. If more than one app shares the same webhook URL and the same user is mapped to each app, Acrobat Sign sends the event once per app. Process event IDs. Do not assume exactly-once delivery.

SX02 and SX-ADB-02 keep downstream_write_count at 1. The first verified notification wins.

Resource webhooks versus account webhooks

Official partner guidance, accessed 9 September 2026, tells integrations to create resource-level, per-agreement webhooks through the API.

Account or group webhooks created in the UI fire for every agreement that user, group, or account sends. You then have to filter platform agreements from everything else. One failed delivery also puts the whole train on a single 72-hour clock. Per-agreement webhooks isolate that clock. They also fail at create time, so you see a webhook problem before customers complain.

USER and RESOURCE scopes are API-only. They are not available in the product UI. Account-level webhooks need an Account admin. Group-level webhooks need a Group admin. Confirm those screens in your tenant. Do not invent a seat price.

After an agreement is terminal, official partner guidance says delete the resource webhook with DELETE /webhooks/{webhookId}. Otherwise the UI fills with dead API webhooks that users cannot remove there.

Official uniqueness is a combination of subscription event, URL, scope or resource type, resource ID, Application ID, and creator. DUPLICATE_WEBHOOK_CONFIGURATION and WEBHOOK_LIMIT_EXCEEDED exist. This page does not invent a numeric ceiling.

72 hours, then disable

Official events guide: failed deliveries retry with a doubling interval. The documented envelope is about 15 retries over 72 hours. After that the webhook is disabled.

No notifications go to that URL until someone activates it again. Notifications between disable and re-enable are lost.

The same page also shows an example that starts with a 30-second first retry, then one minute. Another sentence starts the doubling at one minute. Treat the 72-hour disablement as the control rule. Do not publish a more precise retry table than Adobe does.

GET /webhooks/{webhookId} tells you whether the webhook is enabled. Official text says that call does not tell you the webhook is failing but not yet disabled.

Official partner guidance: keep a polling backup, recreate per-agreement webhooks that failed to create, and give operators a manual update-status control for one critical agreement.

Complete is a retrieval signal

Official events guide: it is acceptable to ask for signed documents in the webhook, and it is often better to retrieve them through the Agreements API after an Agreement Status Complete event.

includeSignedDocuments returns base64 on AGREEMENT_WORKFLOW_COMPLETED only. Official payload overview: payloads are limited to 10 MB. If the event is larger, Acrobat Sign strips conditional parameters in this order:

1. includeSignedDocuments
2. includeParticipantsInfo
3. includeDocumentsInfo
4. includeDetailedInfo

The payload then includes conditionalParametersTrimmed so you know what disappeared. Filing the final PDF from a trimmed payload is how teams store a truncated file.

SX07 keeps status waiting_for_downloadable or payload_truncated until the Agreements API returns the combined document and, if you need it, the audit report. SX-ADB-04 walks complete, then retrieve, then one file write.

Official REST samples show combined-document and audit-report download patterns. Confirm the current endpoint paths in your tenant. This page does not vendor those sample trees.

Adobe APPROVER is not DecisionEvidence

Official payload vocabulary includes participantRole values such as SIGNER, APPROVER, ACCEPTOR, FORM_FILLER, and CERTIFIED_RECIPIENT. Those are vendor-hosted roles on the agreement.

This page covers the Acrobat Sign webhook adapter. Recipient signing order and an Adobe APPROVER step may implement a vendor-hosted gate. Acrobat Sign workflow products may exist in a tenant. Those surfaces do not automatically become Flowgrammer Document Approval DecisionEvidence.

If the organization still needs a named approve, reject, or request-changes decision, open the published Document Approval Workflow. SX11 records that path. Do not treat participantRole=APPROVER as the org SoR.

Forbidden downstream

These writes stay blocked after a verified complete:

• Payment
• Supplier bank-detail change
• Final accounting post
• Auto-renew
• Auto-terminate
• A legal-validity conclusion as an automation outcome

Use invoice processing automation when money is the job. Use the contract tracker when renewal or termination is the job. Use intelligent document processing when extraction is the job.

HTTPS is required. Official events guide: only HTTPS URLs are valid, TLS 1.2 is required, and TLS 1.0, 1.1, and 1.3 are not supported for webhooks. Two-way SSL is optional through account Security Settings. IP validation rejects loopback and other reserved ranges at create time. Confirm those screens. Do not invent an IP allowlist here.

OAuth scopes webhook_read and webhook_write are required for the list and create or update calls. Official events guide names webhook_retention for DELETE. The Webhook APIs page names webhook_delete. Treat that string as a tenant-confirmed limit. Do not hard-code one name as the only truth.

Worked example

Fictional Cedar & Quay Fabrication Ltd sends supplier agreement DOC-CQ-SIGN-014 through Acrobat Sign.

• Named sender: Jordan Hale
• Signer: Morgan Reid, role SIGNER, order 1
• Human gate: Avery Chen
• Library document: tmpl:cq-sign-014 version v1.0
• Agreement id: FICTION-CQ-AGREEMENT-014
• Webhook notification id: FICTION-CQ-WHN-014
• Application ID: FICTION-CQ-ADOBE-CLIENTID
• Scope: RESOURCE on that agreement
• Next action after verified complete: notify Avery, then file the retrieved PDF

SX01 is the clean path. Intent GET echoes the fiction Application ID. Notify POST echoes it again. ACK returns 2XX in 180 ms. Work is queued. The listener waits for AGREEMENT_WORKFLOW_COMPLETED with agreement status Complete, retrieves the combined document, and writes one SignatureEvidence row. artifact_ready becomes yes. downstream_write_count is 1.

SX02 replays the same webhookNotificationId. The second notify is acknowledged. The row is not written again.

SX03 and SX-ADB-01 send a wrong CLIENTID. The listener returns a non-success response. No SignatureEvidence write.

SX07 arrives as complete with includeSignedDocuments trimmed. Status stays payload_truncated until the API download succeeds.

SX09 tries to pay the supplier from complete. The write is blocked.

SX11 finds an org approval still open. The listener does not treat Adobe APPROVER as SoR. It points to Document Approval.

Workflow

1. Bind DOC-CQ-SIGN-014 version v1.0 and name Jordan Hale as sender.
2. Create the agreement. Capture agreement.id.
3. Create a RESOURCE webhook on that agreement. Confirm intent GET echoes your Application ID.
4. Subscribe to the events you actually handle. Do not subscribe to every event because it is available.
5. On notify POST, echo CLIENTID, return 2XX, and enqueue the payload.
6. Dedupe on webhookNotificationId.
7. Map agreement.id, event name, sender, roles, and routing into SignatureEvidence.
8. On decline or recall, mark the row terminal. Do not file a signed PDF.
9. On AGREEMENT_WORKFLOW_COMPLETED or status Complete, retrieve the combined document through the API.
10. If conditionalParametersTrimmed includes includeSignedDocuments, do not file the payload PDF.
11. Avery Chen decides the notify or file action.
12. If the webhook fails to create or later disables, poll status and recreate the resource webhook.

Decision table

Human gates

A named sender confirms the bound document and library version before send. A named person confirms the HTTPS URL, Application ID inventory, OAuth webhook scopes, and ACCOUNT, GROUP, USER, or RESOURCE scope before promising a listener. A named person reviews failed CLIENTID echo, missing webhookNotificationId, ack_timeout, webhook_disabled, payload_truncated, decline, recall, and waiting_for_downloadable. A named person decides any post-sign notify or file action.

Automation may ACK quickly and queue work. It may not invent legal validity, org approval, payment, bank-detail change, final accounting, auto-renew, or auto-terminate.

Failure paths

• Missing agreement.id or webhookNotificationId
• Missing or wrong CLIENTID echo on GET or POST
• Empty 200 treated as success
• Sync PDF work that exceeds about five seconds
• 72-hour retry exhaustion that disables the webhook
• Notifications lost while the webhook is disabled
• ACCOUNT fan-out treated as one agreement
• includeSignedDocuments filed after 10 MB truncation
• Unauthorized sender
• Auto-pay or auto-renew
• Adobe APPROVER treated as Document Approval DecisionEvidence

Test cases

What to measure

Record webhooks created, share of GET and POST echoes that pass before write, duplicate notifications suppressed, ACK times over the five-second window, declines and recalls that did not file a signed PDF, waits for retrieval, truncation count, disabled webhooks, and completes that have a notify or file ref. Keep those as definitions. Do not invent a benchmark, accuracy rate, or ROI figure.

There is no live production webhook metric here, and no Flowgrammer customer signing case.

How to use the test pack

Download the Adobe Sign Webhook Verification Pack. It is an original fixture pack, not an Adobe Exchange listing and not a hosted listener.

1. Read README.md, then markdown/setup.md.
2. Walk csv/clientid-echo-tests.csv.
3. Confirm CE01 and CE02 pass and CE03 fails when the CLIENTID is wrong.
4. Confirm SX-ADB-01 fails a GET without an echo.
5. Confirm SX07 waits and SX-ADB-04 files only after retrieval.
6. Walk SX01 through SX12, then the six Acrobat Sign extras.
7. Keep markdown/forbidden-downstream.md next to any post-sign handoff.

The useful rules also sit on this page so the download is not the only answer.

Realistic limitations

• This page designs Acrobat Sign signing control. It does not certify legal validity in any jurisdiction.
• Application ID, OAuth webhook scopes, Account or Group admin authority, USER and RESOURCE API-only scopes, two-way SSL, and IP validation can be plan-gated or admin-gated. Confirm the current official tables in your tenant.
• The DELETE scope string conflicts across official pages. Confirm webhook_retention versus webhook_delete before you ship a delete call.
• WEBHOOK_LIMIT_EXCEEDED exists. This page does not invent a numeric ceiling.
• The retry example that starts at 30 seconds and the sentence that starts doubling at one minute are both official. Public copy uses the 72-hour disablement rule and does not invent a finer table.
• JSON field names can vary by webhook generation. Accounts still on classic webhooks after 14 March 2023 may see empty initiatingUser fields. Map the event identity you actually receive.
• Combined-document and audit-report endpoint paths should be confirmed on the current REST reference.
• This system does not approve a document for the organization, extract fields, pay anyone, or change supplier bank details.
• This guide does not rank vendors and is not a pricing page.
• The published DocuSign vs Adobe Sign guide is the vendor-to-vendor decision page. The published PandaDoc E-Signature Automation adapter is live.
• This page is operational guidance, not legal advice and not a compliance certification.

Next step

Download the Adobe Sign Webhook Verification Pack for CLIENTID echo vectors, timeout notes, and the eighteen cases.

Keep the published E-Signature Automation hub nearby for the shared model. Keep the Document Approval Status and Role Matrix nearby when an org decision is required.

If webhook enablement, Application IDs, or the event log are still unclear, start with an AI Success Audit. If those pieces are already named, book a fit call to scope an AI Automation Systems build.

Sources

• Flowgrammer, "E-Signature Automation", Flowgrammer, accessed 2026-09-09, /insights/e-signature-automation
• Flowgrammer, "Signing Workflow Requirements Workbook", Flowgrammer, accessed 2026-09-09, /resources/e-signature-signing-workflow-workbook
• Flowgrammer, "DocuSign E-Signature Automation", Flowgrammer, accessed 2026-09-09, /insights/docusign-e-signature-automation
• Flowgrammer, "Dropbox Sign E-Signature Automation", Flowgrammer, accessed 2026-09-09, /insights/dropbox-sign-e-signature-automation
• Flowgrammer, "Document Processing Automation: What to Automate First", Flowgrammer, accessed 2026-09-09, /insights/document-processing-automation
• Flowgrammer, "Document Approval Workflow", Flowgrammer, accessed 2026-09-09, /insights/document-approval-workflow
• Flowgrammer, "Document Approval Status and Role Matrix", Flowgrammer, accessed 2026-09-09, /resources/document-approval-workflow-template
• Flowgrammer, "Invoice Processing Automation: Workflow & Test Pack", Flowgrammer, accessed 2026-09-09, /insights/invoice-processing-automation
• Flowgrammer, "Intelligent Document Processing (IDP): How It Works", Flowgrammer, accessed 2026-09-09, /insights/intelligent-document-processing
• Flowgrammer, "Contract Tracker", Flowgrammer, accessed 2026-09-09, /insights/contract-tracker
• Adobe, "Webhooks in Acrobat Sign", Adobe Developer, accessed 2026-09-09, https://developer.adobe.com/acrobat-sign/docs/overview/acrobat_sign_events/
• Adobe, "Webhook Event Payload Overview", Adobe Developer, accessed 2026-09-09, https://developer.adobe.com/acrobat-sign/docs/overview/acrobat_sign_events/webhookpayloadoverview
• Adobe, "Webhooks for Partner Integrations", Adobe Developer, accessed 2026-09-09, https://developer.adobe.com/acrobat-sign/docs/overview/techblog/tldr/webhooks-partner-integrations
• Adobe, "Webhook APIs", Adobe, accessed 2026-09-09, https://opensource.adobe.com/acrobat-sign/developer_guide/webhookapis.html
• Adobe, "REST API Samples", Adobe, accessed 2026-09-09, https://opensource.adobe.com/acrobat-sign/developer_guide/samples.html
• Adobe, "Developer guide overview", Adobe, accessed 2026-09-09, https://opensource.adobe.com/acrobat-sign/developer_guide/