Ignisign
DOCS & KNOWLEDGE · FILES & DOCS
Signature requests, signers, and documents in the account they connected.
Connecting Ignisign in practice
Ignisign issues a separate skv2_ API key for each of its three environments — Development, Staging and Production — so promoting a working e-signature integration means re-keying rather than re-pointing. Its webhooks carry a verificationToken that you have to post back to Ignisign to validate if you are not using one of their SDKs, and your endpoint must answer 200 OK or the event counts as unreceived.
Scopes that draw scrutiny
skv2_ API key (per application, per environment)Sent as Authorization: Bearer and created in the console per environment. It is the whole grant — there is no narrower permission to request, so a production key can do everything the application can, including creating signature requests in the customer’s name.
Worth knowing
- Without an SDK, webhook verification is an extra outbound call: you send appId, appEnv and verificationToken to Ignisign’s verification endpoint. The SDKs check appId and appEnv and verify the token for you.
- Every webhook delivery must return 200 OK to confirm reception, so a handler that queues work and returns 202 will be treated as having failed.
- Events are grouped into seven families — signer, signature request, signature session, signature proof, signature images, application and document request — so one endpoint has to fan out across all of them.
- Because keys are environment-scoped, a staging key silently produces no production signature proofs rather than erroring in an obvious way.
Checked against API integration quick win (2026-09-29), Webhooks (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Ignisign behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.