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.
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- 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.
- 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.
- GET
/v1/documents/{id}/pages/{n}One page as PDF, for a client that has to show the paper.
- 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.
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:readThe list, one template’s documents, roles, subjects, questions and fields, and the geometry of every field.
templates:writeAuthor a template from an uploaded PDF. What extraction produces is what every envelope made from it asks for.
envelopes:readOne envelope: its status, its recipients and their delivery state.
envelopes:writeCreate, send and mint embedded signing URLs. This is the scope that emails real people and spends allowance on a live key.
documents:readThe pages of a document belonging to a template this key can already see, as PDF.
webhooks:readThe registered endpoints. Never their signing secrets.
webhooks:writeRegister, change, rotate and delete endpoints — which decides where a copy of recipient names and addresses goes.
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.
envelope.completedenvelope.declinedenvelope.voidedenvelope.sentenvelope.expiredrecipient.completedA `Vumasign-Signature` header over the timestamp and the body together, hex-encoded. Not `X-Vumasign-Signature` — RFC 6648 deprecated the `X-` convention in 2012.
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.
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.
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.
-- npx -y @vumasign/mcp
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
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 month | Included |
|---|---|
| From 51 | R10 |
| From 500 | R9 |
| From 2 000 | R8 |
Read the specification first.
It is public, unauthenticated, and the fastest way to find out whether this API fits what you are building.