Lifecycle

Decline, expire, and remind — the full signing-request lifecycle.

A signing request is no longer just “pending → completed.” NoSign tracks a full lifecycle, and every transition emits its own webhook event.

States

State	Meaning	Terminal?
`pending`	Created, awaiting the first signer	no
`in_progress`	At least one signer has acted, others remain	no
`completed`	All signers signed; the PDF is sealed and the webhook fires	yes
`declined`	A signer declined; an optional `decline_reason` is captured	yes
`expired`	The request was not completed within its window	yes

Decline

A signer can decline instead of signing. The request enters the terminal declined state, an optional decline_reason is recorded in the audit trail, and a signing.declined webhook fires. No further signers are emailed.

Expiry

Unsigned requests expire after a configurable window (default 30 days). A scheduler moves them to the terminal expired state and fires a signing.expired webhook. Expiry is the safety net against requests lingering forever with personal data attached.

Reminders

Before expiry, NoSign sends the current signer reminder emails on a configurable cadence (default 7 / 3 / 1 days before the deadline). Reminders are tracked per request so a signer is never reminded twice for the same checkpoint.

Checking status

Your platform can poll a request and its per-signer status at any time:

GET /v1/signing-requests/{id}

{
  "id": "sr_8fk2",
  "status": "in_progress",
  "expires_at": "2026-07-11T09:00:00Z",
  "signers": [
    { "email": "ada@example.com", "status": "signed" },
    { "email": "grace@example.com", "status": "pending" }
  ]
}

Field names are illustrative. Verify against your NoSign instance’s API.

The webhook remains the primary, push-based notification path — polling is for reconciliation, not the happy path.

← Field types Evidence layer & verification