Introduction
The inSigner Cloud API lets you create, send, and manage legally-binding electronic signatures from your applications. It’s a RESTful JSON API secured with API keys.
Base URL
Section titled “Base URL”All API requests use the following base URL:
https://app.insigner.co/api/v1Versioning
Section titled “Versioning”The API is versioned via the URL path (/v1). Breaking changes are only introduced in new major versions. Non-breaking additions (new fields, new endpoints) may be added to v1 at any time.
Key concepts
Section titled “Key concepts”| Concept | Description |
|---|---|
| Document | A PDF or image that requires signatures. Goes through a lifecycle: draft → pending → completed. |
| Signer | A person who needs to sign, approve, or view a document. Each signer receives an email with a unique link. |
| Field | A form element placed on a document page — signatures, text inputs, checkboxes, dates, etc. |
| Template | A reusable document blueprint with pre-configured fields and signer slots. |
| Campaign | A public signing link based on a template. Anyone with the link can submit a signed copy. |
| Bulk Send | Send the same template to hundreds of recipients in one API call. |
| Webhook | An HTTP callback that notifies your server when events occur (e.g. document signed). |
Document lifecycle
Section titled “Document lifecycle”draft → pending → completed ↓ declined / cancelled / expired- Draft — Document is created. Add fields, signers, and upload the PDF.
- Pending — Document has been sent. Signers receive email notifications.
- Completed — All signers have signed. The signed PDF is available for download.
Response format
Section titled “Response format”All successful responses return a JSON object with a data key:
{ "data": { ... }}List endpoints also include meta for pagination:
{ "data": [ ... ], "meta": { "count": 10, "hasMore": true, "nextCursor": "clx1abc123" }}Every response includes an X-Request-Id header (e.g. req_abc123...) for debugging and support.