SignatureKit
Provider APIs

Provider request shapes

Each provider package exposes the request facts its upstream API supports.

Provider APIs create upstream signing ceremonies. They are not local Signatures backends: the provider owns links, notifications, recipients, envelopes, and audit UX. SignatureKit keeps the calls boring: typed input, Redacted credentials, SignatureHttpClient, and SignatureKitError on recoverable failures.

npm install @signature-kit/http @signature-kit/clicksign @signature-kit/assinafy @signature-kit/zapsign @signature-kit/docuseal @signature-kit/documenso

Providers

Clicksign

v1 document + signer flow, one document per request.

Assinafy

Document, signer, and assignment inside an account.

ZapSign

Bearer-token PDF upload with first signing URL.

DocuSeal

Open-source PDF submissions with submitter links.

Documenso

Open-source v2 envelopes with optional distribution.

Provider-owned request shapes

Each signer package defines the documents, recipients, routing, status values, and limits its upstream API actually supports. Clicksign, Assinafy, and ZapSign encode their single-document constraints in their local resource-props schemas; DocuSeal and Documenso keep multi-document provider models.

Local vs remote

Use @signature-kit/pdf + Signatures when SignatureKit must sign bytes. Use provider request functions when an upstream platform owns the ceremony.

How is this guide?

Typed error channel

Every SignatureKit failure is a SignatureKitError in Effect's error channel — discriminate by code with Effect.catchTag/catchIf, no throw.

Clicksign

Create Clicksign v1 document requests with Redacted credentials and typed SignatureKit errors.

On this page

ProvidersProvider-owned request shapes