What if the same agreement event arrives twice?

The workflow finds the existing Notion page by Adobe Sign agreement ID before deciding whether to create or update, so duplicates never make new rows.

What happens when webhook events arrive out of order?

Each incoming event carries a timestamp. Before overwriting status in Notion, we compare it to the last-modified timestamp already stored on the row and skip the update if the incoming event is older.

Can I point this at a contracts database I already use?

Yes. As long as you add an "Agreement ID" property (or point the workflow at whichever property name you use for it), we will match existing rows on that key instead of creating duplicates.

Does this work if our Adobe Sign account is on the EU, Australia, or Japan data centers?

Yes. The workflow uses the account-specific access point that Adobe returns during authentication, so it works on any Adobe Sign region.

Do signer and counterparty names show up automatically?

Yes. After the webhook fires, we pull the full participant list from Adobe Sign so the Notion row always has the current signer emails and counterparty names.

Mirror Adobe Sign agreements into a Notion contracts database

Every time an Adobe Acrobat Sign agreement changes state, I want to mirror that agreement into our Notion contracts database so legal and ops have one live source of truth. This is deterministic and should run as code, not an agent.

Trigger: a webhook from Adobe Sign firing on agreement lifecycle events. I want to react to sent, signed, completed, cancelled, expired, and rejected. Ignore other event types.

When a webhook arrives, extract the Adobe Sign agreement ID and the event timestamp from the payload. Then call Adobe Sign Get Agreement to pull the latest metadata for that agreement (name, status, senderEmail, createdDate, lastModifiedDate, and the participant set summary), and Adobe Sign Get Agreement Members to pull the full participant list so we can capture counterparty name(s) and signer emails.

Next, use Notion Query a Data Source against the contracts database, filtering the "Agreement ID" property equal to the Adobe Sign agreement ID. The result tells us whether a page already exists for this agreement.

If no page exists, call Notion Create a Page under the contracts data source and populate the properties: title (the agreement name), Agreement ID (the Adobe Sign agreement id — this is the deterministic key), Counterparty (comma-joined names of non-sender participants from Get Agreement Members), Sender (senderEmail), Status (the Adobe Sign status: OUT_FOR_SIGNATURE, SIGNED, COMPLETED, CANCELLED, EXPIRED, REJECTED — map to friendly labels if the client has a status select configured), Sent Date (createdDate), Last Modified (lastModifiedDate), Signer Emails (comma-joined emails of signer participants), and Agreement Link (a URL back to the agreement in Adobe Sign, of the form https://secure.<shard>.adobesign.com/account/agreements/<agreementId> using the account's data center).

If a page already exists, call Notion Update a Page for that page id and refresh the same fields, with one guardrail for out-of-order events: before overwriting Status and Last Modified, compare the incoming lastModifiedDate from Get Agreement to the Last Modified value already stored on the Notion page. If the incoming timestamp is older or equal, leave Status and Last Modified alone (but still refresh Counterparty and Signer Emails, since those are derived from the current agreement snapshot). If the incoming timestamp is newer, overwrite Status and Last Modified as well. This makes the workflow safe against webhook retries and out-of-order delivery.

Configuration the user should be able to set: the Notion database (data source) id, the exact Notion property names for Agreement ID / Counterparty / Sender / Status / Sent Date / Last Modified / Signer Emails / Agreement Link (defaults to those names), and the set of Adobe Sign event types that should trigger the sync.

Error handling: if Get Agreement returns RESOURCE_NOT_FOUND, log and exit (the agreement may have been deleted). If Notion Query a Data Source returns more than one page for the same Agreement ID, update the most recently edited one and log a warning about the duplicate. Honor Retry-After on 429s from both services.

What it does

Reacts the moment an Adobe Acrobat Sign agreement is sent, signed, completed, cancelled, expired, or rejected
Creates a new page in your Notion contracts database if one does not exist yet, or updates the existing page keyed by the Adobe Sign agreement ID
Keeps counterparty, sender, status, sent date, last-modified date, signer emails, and a link back to the agreement in sync
Tolerates out-of-order events by only overwriting the status when the incoming event is newer than what is already stored in Notion

What you’ll need

An Adobe Acrobat Sign account that can receive agreement lifecycle events
A Notion workspace with a contracts database shared with the connection
An "Agreement ID" property on that Notion database so each contract row can be matched back to its Adobe Sign record

How to customize it

Which agreement events count — you can narrow to just signed and completed, or include sent, cancelled, expired, and rejected
Which Notion database receives the rows and what your property names are (counterparty, sender, status, sent date, agreement link)
Any extra fields you want mirrored, like contract value, deal owner, or a project code pulled from the agreement name

Use cases

Data Sync

Mirror Adobe Sign agreements into a Notion contracts database

Integrations

Type

Categories

What it does

What you’ll need

How to customize it

Use cases

FAQs

Related prompts