Update, suspend and archive accounts

PATCH /api/partner/v1/accounts/{id} (or PUT) changes any of name, branding, timezone, locale, test_mode and status. Fields you omit are left alone. branding takes the same keys and validation as at provisioning and merges into the stored values; a blank string clears a key.

curl -X PATCH https://spitshake.io/api/partner/v1/accounts/412 \
  -H "Authorization: Bearer $SPITSHAKE_PARTNER_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "status": "suspended", "status_reason": "Invoice 2026-10 overdue" }'

The response is the account, as GET /api/partner/v1/accounts/{id} returns it, including status, suspended_at and archived_at. List accounts in one status with GET /api/partner/v1/accounts?status=suspended.

Lifecycle

`status`	What happens
`active`	Normal access. Setting `active` on a suspended account reactivates it.
`suspended`	Every API token, OAuth token and user session of the account gets `403 {"code": "account_suspended"}`, including on the OAuth consent and application screens; logging out still works. Embed tokens and every signing link already sent are refused (signers see “document not available”), so nothing new can be signed. Signed records stay available: public document links (`/dl/...`) keep serving the signed documents and the audit trail, and a signer who already finished still sees their completed page (ESIGN/UETA retention). No email, SMS or reminder goes to its signers (see postponed invitations). Nothing is deleted, and reactivating restores all of it.
`archived`	The same refusals (`"code": "account_archived"`), and final through the API: further changes, token minting, webhook configuration and template copies answer `409`, including a request that was already in flight when the archival committed. Revoking tokens and deleting webhooks still work. Data, signed documents and the audit trail are kept.

Postponed invitations

An invitation that was already queued when the account was suspended (a new submission’s emails, or the next signer of a sequential order once the previous one finished) is postponed, not sent: the signer stays waiting with no sent_at, and no invitation_sent entry is added to the submission’s audit trail. Nothing re-sends it automatically, because a firm returning weeks later may not want stale invitations to go out. After reactivation the firm (or you, with a token for the account) resumes each one with POST /api/submitters/{id}/resend. The ones to look at are signers still waiting with no sent_at on a pending submission; in a sequential order only the first of them is due. Every change is audited on the account: partner.account_updated (with the changed field names), partner.account_suspended, partner.account_reactivated and partner.account_archived (with status_reason when given).

Suspending a partner (an operator action) blocks only the Partner API. Suspending an account blocks that firm’s own access and its signing links, but not its signed records.

Overview

Partner API

Templates

Thumbnails

Submissions

Submitters

Users

Access Tokens

Webhooks

Settings

Custom Domains

Brands

Teams

Audit Events

MFA

BAA

Security Events

Subscriptions

Plans

Payments

Verification

KBA

AI

Embed

Health

Update, suspend and archive accounts

Lifecycle

Postponed invitations

​Lifecycle

​Postponed invitations

Lifecycle

Postponed invitations