Signing lifecycle

A signing groups the agreements you want signed and the recipients who must act on them. Start with a draft, add your content and recipients, then send it. The same lifecycle applies to uploaded PDFs and contracts created from templates.

For a first implementation, follow Send a PDF or the Contracts guide. This page explains the decisions shared by both workflows.

Lifecycle overview

Stage	What your integration does
Draft	Upload PDFs or create contracts, prefill values, and add or reorder recipients.
Sent	Call the send endpoint. Krebit Sign invites recipients according to the signing order.
In progress	Read status, handle events, and send reminders when needed. Contract recipients complete fields before signing the generated PDF.
Completed	Download signed documents and retrieve contract values.
Cancelled	Stop an active signing and record the cancellation in your application.

is_draft, is_completed, and cancelled_at describe the signing's state. Document and contract completion are tracked separately; completing one document does not necessarily complete the whole signing.

Choose your content

• Upload a PDF when your application creates the finished document. Uploads use selected_file in a multipart request and must meet the document endpoint's requirements.
• Create a contract from a template when recipients should fill in fields. You can prefill values, then send the contract without uploading a PDF. See the Contracts guide.

A signing can contain multiple documents or contracts. Keep the signing ID and the returned document or contract IDs in your application's records.

Recipient experience

Each recipient has a name, email address, and signing_method: email, bankid, or approval. Identification before opening the signing is a separate setting. Check the recipient endpoint for the required identification fields.

Choose parallel or sequential for the signing's signing_order. Approvers act before signers; sequential signing then invites signers in order.

Recipients receive an order when added. To change it while the signing is a draft, use Update recipient order. Its order value is zero-based within the recipient's type group. Read the recipients again after reordering to obtain the resulting order.

The user who authorizes your API connection is separate from these recipients. See Connected user if your application needs to show which account is connected.

Send and track the result

Use POST /api/1.0/signings/{signing}/send once the draft contains content and recipients. After sending, draft edits are no longer available.

Subscribe to signing.document.completed to learn when a document is signed. The event includes the document and signing IDs. For documents generated from contracts, contract_id links to the final field values.

Use GET /api/1.0/signings/{signing} to check whether the whole signing is complete. Use the document or contract endpoints for their individual results:

• Document completed_at: all signatures on the document are complete.
• Contract completed_at: the contract has been finalized as a PDF.
• Contract signed_at: all signatures on its generated document are complete.

Reminders and cancellation

Use Remind unsigned recipients for recipients still eligible for reminders. The individual reminder endpoint returns an error if the recipient is not eligible; inspect its response instead of assuming an invitation was sent.

Use Cancel a signing to stop an active signing. Keep cancellation distinct from successful completion in your application's status display.

Next step

Webhooks and results shows how to register a listener, verify events, and retrieve the completed documents and values. For pagination, errors, and safe retries, see API conventions.