Products

Industries

Resources

Developers

Migrate from Adobe Sign to Anvil

Adobe Sign is the most enterprise-shaped provider of the set, and most of the work is collapsing its access model rather than its documents. The plugin does that first.

Get started free View the plugin

Install in Claude Code

/plugin marketplace add anvilco/anvil-plugins
/plugin install adobesign-anvil-migration@anvil-plugins

Type both into Claude Code: the first adds Anvil's plugin catalog, the second installs the Adobe Sign plugin. Then ask Claude to migrate.

The mental model

An Adobe agreement built from a library document becomes an Anvil Etch packet built from a Cast, and Adobe’s participant sets, form fields, merge fields, signing URLs, and webhook events become Anvil signer IDs, field aliases, prefill data, embedded sign URLs, and webhook actions.

Cast is Anvil's word for a template: a reusable document with named fields your code fills through the API.

The access model is most of the migration

Three Adobe layers disappear: bearer tokens become one ANVIL_API_KEY, GET /baseUris shard discovery gives way to a single host, and x-api-user impersonation moves into your app.

export-adobesign-templates.ts

Exports your library documents as PDFs with a manifest of roles, fields, and sharing mode. Standalone, with no Adobe SDK required.

Adobe Sign to Anvil, term by term

Most of a migration is vocabulary. Here is the map the plugin works from – it keeps these names straight so you do not have to.

Adobe Sign	Anvil	What it is
Agreement	Etch packet	The signing transaction. createEtchPacket returns an etchPacketEid.
Library document (libraryDocumentId)	Cast (castEid)	A reusable PDF template with form fields.
Transient document	Uploaded file (createCast)	A file uploaded for one-time use; Adobe expires it after 7 days.
Participant set	Signer(s)	A recipient slot at one routing step; its members are alternates.
Participant role (SIGNER, APPROVER)	Signer id / non-signing recipient	The kind of participant; in Anvil an arbitrary signer id mapped to fields.
Form field	Field	A fillable or signable box on the PDF, each with a type.
mergeFieldInfo[]	Fill data (data.payloads)	Prefilled field values keyed by alias.
order (participant set)	routingOrder	Signing order. Adobe is sequential across sets.
state (IN_PROCESS / DRAFT)	send (default) / isDraft	Send immediately vs. save as a draft.
esignUrl	generateEtchSignURL	The embedded signing URL.
AGREEMENT_WORKFLOW_COMPLETED	etchPacketComplete	All participants done; documents downloadable.
OAuth / integration key + baseUris + x-api-user	ANVIL_API_KEY	Auth. One key, one host, no x-api-user. OAuth or child orgs act for a client.

What the rewrite looks like

Sending from a library document is one call on both sides, but Anvil drops the base-URI discovery step and flattens participant sets into signers.

Before – Adobe Sign

// baseUri comes from GET /baseUris, or from api_access_point on the OAuth token.
const res = await fetch(`${baseUri}/agreements`, {
  method: 'POST',
  headers: { ...authHeaders, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    fileInfos: [{ libraryDocumentId: 'CBJCHBCAABAA...' }],
    name: 'NDA for Acme Corp',
    participantSetsInfo: [
      {
        memberInfos: [{ email: 'jane@example.com' }],
        order: 1,
        role: 'SIGNER',
      },
    ],
    signatureType: 'ESIGN',
    state: 'IN_PROCESS', // 'DRAFT' or 'AUTHORING' would hold it
    mergeFieldInfo: [{ fieldName: 'CompanyName', defaultValue: 'Acme Corp' }],
  }),
})
const { id: agreementId } = await res.json()

After – Anvil

const {
  data,
  errors,
} = await anvilClient.createEtchPacket({
  variables: {
    files: [ ... ],
    data: { ... },
    signers: [ ... ],
  },
})

No base-URI lookup before this call, and no x-api-user header. Acting for a client is set up on the account rather than passed per send.

How the migration runs

The plugin works through six steps, showing you what it found and what it plans to change before it touches your Adobe Sign integration.

Step 1 of 6

Discovery

Scans your codebase for every integration point – SDK imports, API calls, environment variables, webhook handlers, and database columns holding provider IDs.

Where Adobe Sign and Anvil differ

No migration is a pure find-and-replace. These are the gaps the plugin raises during mapping – each tagged with what it will cost you to close, from a straight swap to a decision worth making up front.

Works the same – A direct equivalent – nothing to decide.

Minor change – The same capability, reached a different way in the API call.

Plan for rework – Supported, but you will write code for it.

Needs a decision – No direct equivalent – worth discussing before you start.

Signing order

Works the same

routingOrder is a direct equivalent, with one caveat: see alternate members below.

Embedded signing

Works the same

The esignUrl becomes generateEtchSignURL in AnvilEmbedFrame.

Merge fields

Minor change

mergeFieldInfo becomes a data payload keyed by field alias.

Agreement metadata

Minor change

externalId and custom fields move to your own database.

Participant roles

Minor change

A per-template naming and field-assignment exercise.

CC and certified recipients

Minor change

Becomes a non-signing recipient or an app-level notification.

Alternate members in a participant set

Plan for rework

Adobe treats set members as alternates, any one of whom may sign. Anvil signers are individuals, so the semantics differ. Easy to miss if you do not use it, real work if you do.

Reject and decline to sign

Plan for rework

A straightforward UI addition with custom state at the app level.

Expiration and reminders

Plan for rework

Handled as app-level scheduling if hard deadlines matter.

Bulk send (MegaSign)

Plan for rework

A loop over createEtchPacket instead of a batch call; the client handles rate limiting.

Signer authentication (phone, KBA, password, government ID)

Plan for rework

Build an auth wall in front of the sign URL if verification is compliance-critical.

OAuth multi-tenant and x-api-user

Plan for rework

Adobe supports acting on behalf of another sender through x-api-user. Anvil supports this: register an Anvil OAuth app for each tenant to authorize, or give each tenant a child organization with its own API key. Both are Enterprise features.

Web forms (widgets)

Needs a decision

Adobe widgets are hosted, reusable public signing forms with no direct Anvil equivalent. Anvil Workflows or embedded packets cover the use case, but it is an architectural decision if widgets carry real traffic.

Wet-ink signatures

Needs a decision

signatureType WRITTEN is not supported. Rarely used, but blocking for any template that depends on it.