Sign API Versions

Skribble's Sign API has three versions. v2 is the current stable version recommended for all production integrations. v3 is available as a preview — try it in non-production environments and share your feedback. Sign API v1 has been deprecated.

At a Glance

Feature	Sign API v2	Sign API v3
Single-document requests	✅	✅
Multi-document requests (up to 50)	❌	✅
Draft signature requests	❌	✅
Signer groups	❌	✅
Observer groups	❌	✅
SES / AES / QES signature qualities	✅	✅
Express QES (xQES)	✅	✅
ZertES and eIDAS compliance	✅	✅
Signature reminders	✅	✅
Attachments	✅	✅

What's New in v3

Multi-Document Requests

A single signature request can contain up to 50 documents. All documents are signed together in one flow, which reduces friction for complex processes that would otherwise require multiple separate requests.

Draft Workflow

Signature requests can be created in DRAFT status and fully configured before being initiated. This lets you assemble documents, add signers, and set options across multiple API calls before committing — no more needing to get everything right in a single create call.

Express QES (xQES)

Both v2 and v3 support Express QES — a streamlined qualified electronic signature flow with identification-related endpoints that allow signers to complete the QES process without leaving your application.

Signer and Observer Groups

v3 introduces groups for both signers and observers:

• Signer groups — define parallel or sequential signing workflows. Signers in the same group can sign in any order; groups are completed sequentially.
• Observer groups — grant stakeholders read-only access to the request and its documents without being part of the signing flow.

Base URLs

Skribble hosts data in two regions. Choose the region that matches your data residency requirements and use it consistently across all API calls.

Region	Sign API v2	Sign API v3
Switzerland (CH)	https://api.skribble.com/v2	https://api.skribble.com/v3
Germany (DE)	https://api.skribble.de/v2	https://api.skribble.de/v3

Migrating from v2 to v3

v3 is not a drop-in replacement for v2 — the signing flow has an extra step and several field shapes have changed. The core difference is that v3 separates document upload, request creation, and signing initiation into explicit steps, giving you full control over each stage before anything is sent to signers.

Preview — Subject to Change

Sign API v3 is a preview release. The API surface may change before general availability.

Step 1 — Upload document(s)

Both versions support pre-uploading documents via POST /documents. In v2 you could also embed the PDF inline when creating the request. In v3, pre-uploading is required — the create endpoint only accepts document_id references.

v2

POST /v2/documents

{
  "title": "Contract Q1 2025",
  "content": "<base64-encoded-pdf>",
  "content_type": "application/pdf"
}

v3

POST /v3/documents

{
  "content": "<base64-encoded-pdf>",
  "filename": "contract-q1-2025.pdf"
}

Both return a document object containing an id — save it for the next step.

---

Step 2 — Create the signature request

In v2, you could bundle the document and even the signers into a single create call and the request would go live immediately. In v3 the request is always created in DRAFT status, giving you time to configure it before anything is sent.

v2 — reference: [Create signature request](/docs/sign-api-v2/create-signature-request)

POST /v2/signature-requests

{
  "title": "Contract Q1 2025",
  "message": "Please sign this contract.",
  "quality": "AES",
  "legislation": "ZERTES",
  "document_id": "<document-id>"
}

The request is immediately OPEN — invitation emails go out as soon as signers are added.

v3 — reference: [Create signature request](/docs/sign-api-v3/create-signature-request)

POST /v3/signature-requests

{
  "title": "Contract Q1 2025",
  "message": "Please sign this contract.",
  "quality": "AES",
  "legislation": "ZERTES",
  "documents": [
    { "document_id": "<document-id>" }
  ]
}

The request is created in DRAFT — nothing is sent yet. You can attach more documents (up to 50), adjust options, or add signers before committing.

---

Step 3 — Add signers

v2 — reference: [Add signer](/docs/sign-api-v2/add-signature-signer)

POST /v2/signature-requests/{SR_ID}/signatures

{
  "account_email": "signer@example.com",
  "sequence": 1
}

Adding a signer to an OPEN request immediately sends them an invitation email.

v3 — reference: [Add signer](/docs/sign-api-v3/add-signature-signer)

POST /v3/signature-requests/{SR_ID}/signatures

{
  "account_email": "signer@example.com",
  "sequence": 1,
  "document_signatures": [
    { "document_id": "<document-id>" }
  ]
}

While the request is still in DRAFT, no email is sent. In v3 you also specify which document(s) each signer should sign via document_signatures — required for multi-document requests.

---

Step 4 — Initiate the signing process (v3 only)

This step does not exist in v2. In v3 you explicitly kick off the process once you are ready:

POST /v3/signature-requests/{SR_ID}/initiate

(no body required)

→ Initiate signature request reference

This transitions the request from DRAFT to OPEN and sends invitation emails to all signers in one go. Nothing reaches your signers until you call this endpoint.