Add eSignatures to Your App: Claude Code API Plugin

The Document eSign plugin for Claude Code removes the afternoon you would otherwise spend reading our API reference. Install it and describe the signing flow you want. Your assistant then writes the integration against the real contract instead of guessing at one.

In short: two commands to install. Eight skills cover everything from authentication through to webhook signature verification, and you build against a free sandbox. Minting a key needs a Business or Ultimate plan; a trial counts.

Install the Claude Code plugin

claude plugins marketplace add AngularMinds/documentesign-api-plugin
claude plugins install documentesign@documentesign

Restart your session and the skills load. There is nothing else to configure, because the plugin ships documentation rather than anything that runs.

Before you write code, get a key. Open Settings, Developer, API keys and mint a test one. That screen needs the Business or Ultimate plan, and a Business trial gives you the same access.

From install to a signed document

1. Install the plugin with the two commands above.
2. Mint a sk_test_ key and put it in your server environment as ESIGN_API_KEY.
3. Ask Claude: "Send a Document eSign document from template X and print the status."
4. Run it. You get a document id back and a signable link within seconds.

Step three is worth trying before anything else. Forty lines of code, working end to end in a few minutes, will tell you more about whether the eSignature API suits your product than any amount of reading.

What the generated integration looks like

Here is the shape Claude produces for a template send. Nothing exotic, which is the point.

// lib/esign.js - server side only, never imported by a client component
const BASE = 'https://api.documentesign.com/v1';

export async function sendFromTemplate(templateId, signer) {
  const res = await fetch(`${BASE}/templates/${templateId}/send`, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.ESIGN_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      recipients: [{ role: 'Client', name: signer.name, email: signer.email }],
      field_values: { contract_value: signer.amount },
      send: true,
    }),
  });

  const body = await res.json();
  if (!res.ok) throw new Error(body.error.message);
  return body;               // { id, status: 'in_progress', recipients: [...] }
}

Store the returned id against your own record straight away. Without it you cannot check status later, fetch the signed PDF, or match an incoming webhook to the right row.

Three things worth asking for

"Add Document eSign to our supplier onboarding so the agreement is signed before the account activates."

Claude reaches for the template path, matches your signer to the template's named role, and prefills the fields you already collected on the signup form. The signer only does the part that needs a human.

"Verify the webhook signature before we trust the payload."

Most integrations get this wrong on the first attempt, and ours did too when we wired up our own demo. The signature covers the raw request body. Parse the JSON first and re-serialize it, and the bytes change, so the check fails every single time with no useful clue as to why. In Express that means capturing the raw buffer before express.json() runs. Claude gets the ordering right because the skill spells it out, with the broken version shown alongside the working one.

"Let people sign inside our app instead of emailing them a link."

Embedded signing is the hardest part of the API to describe in prose. Three details decide whether it works. The link you drop into an iframe is short-lived and carries a signed envelope, so it is safe to render but useless once it expires. The framing origin has to be on your workspace allowlist first. And the browser message announcing a signature is a hint for your interface, while the webhook is what your database should believe. All three are covered, along with why that last distinction matters.

Build against the sandbox, then flip one variable

Every key is either sk_test_ or sk_live_, and neither can see the other's documents. A sandbox document renders and signs exactly like a real one, so your flow gets a faithful rehearsal. What it will not do is email anyone or appear on an invoice, and it carries a watermark so nobody mistakes it for a binding contract.

Consider what that buys you. A loop bug on a live key sends real agreements to real people, some of whom will call you about it. The same bug on a test key reaches nobody. Build there first.

Going to production means minting a live key and changing ESIGN_API_KEY. Your code does not move, because both modes share one base URL and one set of endpoints. Our security practices guide covers where that key should live once it is real.

What the plugin will not do

It writes code. It does not touch your account.

There is no MCP server inside it and no tools it can call, so installing it gives Claude no path to your documents. Your API key sits in your own environment and is read by the integration running on your machine, which is where a credential of that weight belongs.

We drew that line deliberately. Installing documentation should be a low-stakes decision you make in a second. Handing something the ability to send contracts from your workspace is a different kind of decision, and the two should not arrive in the same command.

The eight skills

Claude picks whichever fits what you asked for. You do not need to name them.

Why this reference does not rot

Documentation decays. An endpoint changes, the guide does not, and someone loses an hour to a call the docs told them to make.

Two things prevent that here. The skills live in the same repository as the API routes they describe, so an endpoint change and its documentation land in one review. Then a conformance check runs against the live OpenAPI document, which our server generates from its own route schemas. A skill that references a removed endpoint fails the check, and the plugin does not ship.

That generated document is public at api.documentesign.com/v1/openapi.json. Point any other assistant or client generator at it. If you want the plugin format itself, Anthropic documents it in the Claude Code plugin reference.

Install it, mint a test key. Then ask for the smallest useful thing you can think of.