Products

Industries

Resources

Developers

Migrate from Dropbox Sign to Anvil

Dropbox Sign splits its API across three classes and pairs your key with a client ID. Anvil is one client, one key – and the plugin moves every call across.

Get started free View the plugin

Install in Claude Code

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

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

The mental model

A Dropbox Sign signature request built from a template becomes an Anvil Etch packet built from a Cast, and its role, merge-field, and embedded-signing concepts become Anvil signer IDs, field aliases, and embedded signers.

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

Templates move as PDFs, with Document AI assisting

Templates download as PDFs and get re-tagged in Anvil, with Document AI detecting the fields for you. A generated database migration maps every old template ID to its new castEid.

migrate-dropboxsign-templates.ts

Downloads your templates from Dropbox Sign as PDFs with a metadata manifest. Standalone – no external dependencies.

Dropbox 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.

Dropbox Sign	Anvil	What it is
Signature request	Etch packet	The request you send to collect signatures. createEtchPacket returns an etchPacketEid.
Template (template ID)	Cast (castEid)	A reusable PDF template with tagged fields.
Role (e.g. "Client")	Signer id	A named signing slot; in Anvil an arbitrary signer id you map to fields.
Merge field / custom field	Field alias + fill data	Values you inject; Anvil keys fill data by aliasId.
signature_id	Signer eid	Identifies one signer on a packet, used to generate their sign URL.
client_id + getSignUrl	signerType: 'embedded' + generateEtchSignURL	In-app signing. Anvil needs no separate client ID.
hellosign-embedded	@anvilco/anvil-embed-frame	The iframe UI for embedded signing.
Signing order	routingOrder	Sequential vs. parallel; equal values sign in parallel.
Bulk Send (BulkSendJob)	Loop createEtchPacket	Send one template to many recipients.
test_mode	isTest	Watermarked, non-billed test documents.
signature_request_all_signed_and_complete	etchPacketComplete	All signers done; documents downloadable.
API key + client_id	ANVIL_API_KEY	Auth. One key for everything – no separate client ID.

What the rewrite looks like

Custom fields become a keyed data payload, and the role on each signer becomes an arbitrary signer id linked to that signer’s fields.

Before – Dropbox Sign

const response = await client.signatureRequest.sendWithTemplate({
  template_ids: ['tmpl_abc123'],
  title: 'NDA for Acme Corp',
  subject: 'Please sign this NDA',
  message: 'Hi, please review and sign the attached NDA.',
  signers: [ ... ],
  custom_fields: [ ... ],
  test_mode: true,
})
const signatureRequestId = response.signature_request.signature_request_id

After – Anvil

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

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 Dropbox 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 Dropbox 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.

Signing order

Works the same

routingOrder is a direct equivalent.

Signing redirect URL

Works the same

Handled by the AnvilEmbedFrame onEvent handler instead – functionally equivalent.

Templates with roles

Minor change

Fields are listed explicitly per signer; a one-time setup per template.

Merge fields

Minor change

Become data payloads keyed by field alias – mostly a structural change in the call.

White labeling

Minor change

Anvil uses CSS themes: more powerful, but you supply a CSS file.

Decline to sign

Minor change

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

Signature request expiration

Minor change

Sign URLs have a TTL; hard expiration needs app-level logic.

Bulk send

Plan for rework

A loop instead of a batch call; the Anvil client handles rate limiting automatically.

SMS authentication

Plan for rework

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

OAuth multi-tenant

Plan for rework

Dropbox Sign’s OAuth lets your app act on behalf of other accounts. 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.