API & embedded signing · a separate product

Signing inside your product, on your domain.

Build the template once, create envelopes from your own system, and hand your user a signing screen that never leaves your application. The specification is public and unauthenticated — read it before you talk to anybody.

Templates
The form is described once.
Upload the PDF, let extraction find the fields, and every envelope made from it asks for the same things in the same places. Your code sends answers, not coordinates.
Subjects
A form can be about people who never sign it.
Dependant 1 is a subject, not a recipient. The API models that difference, which is why one application can collect six sets of details and be signed by two people.
Envelopes
Building is not sending.
Create an envelope, check it, then call send — two calls, deliberately. A bug in your loop costs you a draft rather than four hundred emails to real customers.
The surface

Small enough to read in one sitting.

Four resources. No SOAP envelope, no account-level XML, no endpoint that exists for a 2011 integration somebody cannot remove.

The OpenAPI document is served to anyone who asks, without a key, so an agent writing your integration can read what is true instead of inventing plausible endpoints.

/api/v1/openapi.json
Templates
  • POST/v1/templatesAuthor from an uploaded PDF. Field extraction runs on it.
  • GET/v1/templatesThe list.
  • GET/v1/templates/{id}Roles, subjects, questions, fields and their geometry.
Envelopes
  • POST/v1/envelopesOne envelope from a template.
  • POST/v1/envelopes/batchesA batch from one template — the bulk send.
  • POST/v1/envelopes/{id}/sendSending is its own call, so building is not sending.
  • GET/v1/envelopes/{id}Status, recipients, delivery state.
  • POST/v1/envelopes/{id}/recipients/{id}/signing-urlAn embedded signing URL for one recipient.
Documents
  • GET/v1/documents/{id}/pages/{n}One page as PDF, for a client that has to show the paper.
Webhooks
  • POST/v1/webhooksRegister an endpoint.
  • GET/v1/webhooksWhat is registered. Never the secrets.
  • POST/v1/webhooks/{id}/rotate-secretRotate without dropping deliveries.
  • DELETE/v1/webhooks/{id}Stop sending there.
Keys and scopes

Two of these spend money or move personal data. They say so.

A key is minted with the scopes you choose and nothing else. Test keys behave exactly like live keys and send nothing to anybody — the difference is the consequence, not the code path.

  • templates:read

    The list, one template’s documents, roles, subjects, questions and fields, and the geometry of every field.

  • templates:write

    Author a template from an uploaded PDF. What extraction produces is what every envelope made from it asks for.

  • envelopes:read

    One envelope: its status, its recipients and their delivery state.

  • envelopes:write

    Create, send and mint embedded signing URLs. This is the scope that emails real people and spends allowance on a live key.

  • documents:read

    The pages of a document belonging to a template this key can already see, as PDF.

  • webhooks:read

    The registered endpoints. Never their signing secrets.

  • webhooks:write

    Register, change, rotate and delete endpoints — which decides where a copy of recipient names and addresses goes.

Webhooks

Six events, not sixty.

Internally the system distinguishes many more — viewed, opened, consented, a sealing failure notified. Publishing all of them would make every one of them a promise we can never rename. These six are the ones a system outside this one waits on.

Outcomes
envelope.completedenvelope.declinedenvelope.voided
Progress
envelope.sentenvelope.expiredrecipient.completed
Signed with HMAC-SHA256

A `Vumasign-Signature` header over the timestamp and the body together, hex-encoded. Not `X-Vumasign-Signature` — RFC 6648 deprecated the `X-` convention in 2012.

The timestamp is inside the signature

Signing the body alone produces a signature that is valid forever, which is a replay nobody can bound. The signed material is timestamp plus body, so an old delivery is detectable as old.

Rotation without downtime

Rotate the secret on a live endpoint and verify against either during the overlap, rather than choosing between a rotation and a gap in deliveries.

MCP

Your AI tools can read. They can’t sign.

Everyone in this category ships an MCP server by now. Ours is a documentation server: three read-only tools over an already-public specification, so a model writing your integration stops inventing endpoints. It has no action tool, and that is a decision rather than a roadmap item — a signing URL is a bearer credential for a legal act, and a model will put it in a transcript, a log, and an error message pasted into a ticket.

Its test suite asserts these refusals against the running program, so they cannot rot quietly.

  • No send_envelope.
  • No mint_signing_url.
  • Holds no credential, and sends no credential header.
  • Spawns no process and writes no file.
claude mcp add vumasign-docs \
  -- npx -y @vumasign/mcp
Pricing

The rate improves on its own.

There are no volume tiers to buy, because a tier makes you predict your volume, over-buy for safety, and negotiate to move. These bands apply when the volume does.

R500 a month is a minimum, not a cap. An API account is never refused for going over it.

Platform plans are priced separately and cannot mint live keys.Platform pricing

API
R500/month minimum

Live keys, embedded signing and the integration surface. 50 envelopes included, then the published rate.

  • Live API keys — the only plan that can mint them
  • Embedded signing URLs, minted per recipient
  • Signed webhooks over the envelope lifecycle
  • Your own sending domain and brand
  • Everything the platform plans do
First 50 each monthIncluded
From 51R10
From 500R9
From 2 000R8
Start building

Read the specification first.

It is public, unauthenticated, and the fastest way to find out whether this API fits what you are building.

Free · 5 envelopes a month · no cardStart free