Sign a PDF with React

Embed signing in a React app, with the API key where it belongs: on your server.

Drop your document here and sign it now. PDF, Word and Excel all work: a .docx or .xlsx is laid out in your browser exactly as it was written, so there is nothing to convert first. Add a signature, a date, a company stamp or a watermark, then download it sealed. Free to start, no account, and the file is never uploaded to open it.

Create a document and get a signing link

React runs in the browser, so this half belongs on your server. What the browser receives is a signing URL, never the API key.

// Your server creates the document and returns only the signing URL.
// The key never reaches the browser.
const { signingUrl } = await fetch("/api/agreements", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ clientId }),
}).then((r) => r.json());

// Then embed it.
export function SignPane({ signingUrl }) {
  return (
    <iframe
      src={signingUrl}
      title="Sign the agreement"
      style={{ width: "100%", height: "80vh", border: 0 }}
      allow="camera"
    />
  );
}

What this ecosystem gets wrong first

Handling the webhook

When a signer completes, we POST the document id, the completion time, the signer record and the SHA-256 fingerprint of the sealed file to your webhook_url. Verify the signature header against the raw request body before you trust any of it, and respond 2xx quickly: do the slow work afterwards, because a webhook that takes ten seconds to answer is a webhook that gets retried.

The fingerprint in that payload is the same value the public verification page checks against, so you can store it and let anybody confirm a document you hold is the one that was signed.

What you get back

The REST API is included on the Business plan at $15 a month rather than sold as an add-on, which is the part worth comparing: several of the platforms a developer evaluates price the API separately and considerably higher.

Other stacks