Skip to main content

​
Changelog

A chronological record of new features, improvements, and important changes to SpitShake.

​
September 2026

​
Embed tokens

  • POST /api/embed/token works. It failed for every caller before.
  • Each account’s tokens are signed with its own key, held by SpitShake. There is no JWT secret to copy or rotate, and the docs no longer describe signing tokens yourself.
  • A form token is accepted only on the signing routes and only for the submission it was minted for; a builder token only on the template routes.
  • Saving a field with a token is refused once the signer has completed or declined, or the link has expired, and is recorded in the audit trail.
  • A scoped API token needs submissions:write to mint a form token and templates:write to mint a builder token.
  • A builder token reads its template. PUT /api/embed/template/{id} answers 422 update_via_templates_api; edit with PUT /api/templates/{id}, which keeps version history.
  • POST /api/embed/submission/{id}/complete always answers 422 complete_on_signing_page: a signer completes on the signing page, which enforces consent, required fields and the audit trail.

​
DocuTrust is now SpitShake

The product, repository, SDK and packages are renamed. Everything written against the old names keeps working:
  • window.DocuTrust is the same object as window.SpitShake, and /js/docutrust-embed.js redirects to /js/spitshake-embed.js.
  • The signing and builder iframes send each event twice, as spitshake:<event> and as docutrust:<event>. Listen for one prefix only, or handlers run twice.
  • A custom domain verifies with either TXT record: _spitshake-verification.<domain> = spitshake-verify=<token> (shown for new domains) or the older _docutrust-verification.<domain> = docutrust-verify=<token>.
  • The MCP server and CLI read SPITSHAKE_API_URL, SPITSHAKE_API_TOKEN and SPITSHAKE_ALLOW_SEND, falling back to the DOCUTRUST_* names.
  • The npm packages are @spitshake/* (they were never published under @docutrust/*).
  • Dashboard users sign in again once, because the session cookie was renamed.

​
Named brands

  • An account can hold several brands, each a named set of signing-page branding (header title, logo, favicon, colours, “Powered by” setting). Manage them in Settings → Brands or through /api/brands (admins only).
  • A template or submission picks one with preferences.brand_id. In the Template Builder, the Brand and Signing domain pickers set it without editing JSON.
  • GET /api/branding_options lists the brands and active custom domains a template editor can choose from.
  • See Brands.

​
Branding

  • Each custom domain carries its own branding, so every submission sent on the domain looks like that brand. Edit it in Settings → Custom Domains → Edit branding or with PUT /api/custom_domains/{id}.
  • New header_color key: the header bar colour, independent of primary_button_color.
  • Field highlights, checkboxes and the signature window now use the brand colour instead of SpitShake’s own.
  • The browser tab shows “display_title or template name - company_name or account name”, and favicon_url (falling back to logo_url) is the tab icon.

​
Custom domains

  • A visitor to a custom domain’s bare address (no signing link) is sent to the domain’s website_url when one is set.
  • embed_src and the other signing links use the submission’s custom domain when one applies.

​
Signing page

  • A signer who reopens a completed link, or submits from a tab left open after signing elsewhere, sees an Already Completed page with a Continue link to the completion redirect, instead of an error.
  • Inline ESIGN consent is the default since 2026-09-23.
  • New template preference signing_nav_style: standard (Previous/Next buttons) or branded_bar (a sticky bar in the header colour). Set it in the Template Builder under Signing Experience.
  • The bottom navigation card names the current field (its label, position such as “3 of 10”, and description) and fills it in place: a text, number, phone or date input, option buttons for a select or radio field, a checkbox toggle, or Tap to sign for a signature or initials. Prefilled and read-only values are shown, not edited. The document scrolls so the field sits between the header and the card. Both signing_nav_style values show it.

​
June 2026

  • The confirmation_modal carousel now lets signers confirm prefilled field values, not just signatures. Flag fields with review_in_carousel: true and they appear as “confirm or update” steps even when already prefilled. (Previously, a flagged field only surfaced when its value was empty.)
  • New document-level toggle: set carousel_review_documents in template preferences to a list of document UUIDs to review every field in those documents — no need to flag fields one at a time.
  • review_in_carousel is now tri-state: true always reviews a field, false opts it out even when its document is flagged, and absent inherits the document setting.
  • Fields hidden by an unmet conditional rule, and stamp fields, are excluded from carousel review steps.

​
April 2026 — Phase 2

​
Witness Signatures

  • Signers can now invite a witness to co-sign a document after completing their own signature via POST /s/:slug/invite_witness.
  • The witness receives a signing invitation and must complete their signature fields before the submission is finalized.
  • Witness invitations are validated: the signer must have completed their form, the witness email must differ from the signer, and the template must define a Witness role.
  • All witness events are recorded in the immutable audit trail (witness_invited, witness_completed).

​
Formula Fields

  • Fields can now include a formula property for dynamic computed values using {Field Name} references and arithmetic operators (+, -, *, /, parentheses).
  • Formula evaluation uses safe arithmetic parsing with no arbitrary code execution.
  • Combine formula fields with the payment field type for dynamic payment pricing based on signer input.

​
DOCX Template Variables

  • DOCX templates now support [[variable_name]] syntax for dynamic content insertion.
  • Conditional blocks with [[if:variable]]...[[end]] for sections that appear only when a variable has a value.
  • Built-in variables: signer_name, signer_email, signing_date, submission_id, template_name.

​
Email 2FA Verification

  • New require_email_2fa template preference that requires signers to verify their email address via a one-time code before accessing the signing form.
  • The 6-digit verification code is sent to the signer’s email and expires after 10 minutes.

​
Reusable Saved Fields

  • Save field configurations for reuse across templates via GET/POST/DELETE /api/settings/saved_fields.
  • Saved fields preserve all properties including type, validation, default values, and options.

​
Angular SDK

  • Published @spitshake/angular — Angular 14+ components for signing forms and template builders with property binding and event binding syntax.

​
n8n Integration

  • Published @spitshake/n8n-nodes-spitshake — custom n8n nodes for automating document signing workflows with trigger and action nodes.

​
CLI Tool

  • Published @spitshake/cli — command-line tool for managing templates, submissions, and settings from the terminal, with CSV bulk import support.

​
New Embed Attributes

  • Signing form: data-custom-css, data-completed-message-title, data-completed-message-body, data-completed-button-title, data-completed-button-url, data-minimize, data-autoscroll-fields.
  • Template builder: data-custom-css, data-input-mode, data-with-signature-id, data-extract-fields.

​
Customizable Reminder Emails

  • Submission preferences now support reminder_subject and reminder_body for custom reminder email templates with token substitution ({{submitter.name}}, {{submitter.link}}, etc.).

​
Subscription Payments

  • New POST /api/payments/subscribe endpoint for collecting recurring subscription payments linked to submissions, with trial period support.

​
Conditional Document Display

  • Templates with multiple documents can now conditionally show or hide documents based on field values using document_conditions in template preferences.

​
Webhook Delivery Logs

  • New GET /api/webhooks/:id/deliveries endpoint to retrieve the full delivery history for a webhook endpoint, including request/response details, timing, and error messages.

​
April 2026 — Phase 1

​
SDK Packages

  • Published official SDK libraries for all major frontend frameworks:
    • @spitshake/react — React 16.8+ components for signing forms and template builders.
    • @spitshake/vue — Vue 3 components with native event binding and kebab-case props.
    • @spitshake/react-native — WebView-based signing and builder components for iOS and Android.
    • @spitshake/api — Typed TypeScript/JavaScript API client for server-side and client-side usage, with full type exports.

​
Signer Delegation

  • Signers can now delegate their signing responsibility to another person via POST /s/:slug/delegate.
  • Delegation is allowed when the submitter status is waiting, sent, or opened.
  • The delegation is recorded in the immutable audit trail (form_delegated event) with from/to details and delegator IP.
  • A form.delegated webhook event is dispatched to all configured endpoints.
  • The new recipient receives a fresh invitation email automatically.

​
QES/AES Signature Levels

  • Three signature levels are now supported: SES (Simple), AES (Advanced), and QES (Qualified).
  • QES provides eIDAS Article 25(2) equivalence to handwritten signatures, verified by a Qualified Trust Service Provider.
  • AES adds SMS OTP or KBA identity verification on top of standard email-based signing.
  • Account-level signature level configuration via GET/PUT /api/settings/signature_level.
  • Per-signature pricing: SES is free, AES is 0.20,QESis0.20, QES is 2.00.

​
Zapier Integration

  • SpitShake is now available on Zapier, connecting to 6,000+ applications.
  • Triggers: Form Completed, Submission Completed.
  • Actions: Create Submission, Create from Emails.
  • Searches: Find Submission by ID, template, or status.

​
MCP Server for AI Agents

  • Published @spitshake/mcp — a Model Context Protocol server that lets AI agents manage documents and signatures.
  • 8 tools available: list_templates, get_template, create_submission, create_submissions_from_emails, get_submission, list_submissions, send_reminder, get_submitter.
  • Works with Claude Code, Claude Desktop, Cursor, and any MCP-compatible client.

​
Date Now Auto-Populate

  • New Date Now field type that automatically populates with the current date when the signer opens the form.
  • Removes friction for date fields that should always reflect the signing date.

​
Form Background Color Customization

  • Account administrators can now set a custom background color for signing forms.
  • Configurable in Settings > Personalization or via the API.
  • Supports any valid CSS color value (hex, rgb, named colors).

​
6 New Languages (14 Total)

  • Added Arabic (ar), Czech (cs), Hebrew (he), Korean (ko), Polish (pl), and Ukrainian (uk).
  • SpitShake now supports 14 languages: English, Spanish, French, German, Italian, Portuguese, Dutch, Japanese, Arabic, Czech, Hebrew, Korean, Polish, and Ukrainian.
  • Both the admin interface and the signing experience are fully translated.

​
Field Validation Presets

  • Pre-built validation patterns for common field types: SSN (XXX-XX-XXXX), EIN (XX-XXXXXXX), ZIP Code (5-digit and ZIP+4), Phone (US format), Date (MM/DD/YYYY), and more.
  • Applied via the field configurator in the template builder.
  • Custom regex patterns remain supported for advanced use cases.

​
Auto-Sign Flag

  • Submissions can now be created with auto_sign: true to automatically apply generated signatures for submitters who have pre-filled signature fields.
  • Useful for internal counter-signatures and automated document workflows.

​
POST /submissions/emails Endpoint

  • New POST /api/submissions/emails endpoint for creating submissions from a list of email addresses in a single request.
  • Each email receives its own submission with an individual signing link.

​
Send Reminder API

  • New POST /api/submitters/:id/remind endpoint to programmatically send reminder emails to submitters who have not yet completed signing.

​
Document Merge on Download

  • When downloading submission documents, all pages are now merged into a single PDF by default.
  • Pass ?separate=true to download individual document files instead.

​
28 New Embed Attributes

  • The <docuseal-form> and <docuseal-builder> web components now accept 28 additional HTML attributes for fine-grained control over the embedded experience, including field skipping, read-only fields, metadata injection, and redirect URLs.

​
Hosted API Documentation

  • Published comprehensive API reference documentation with interactive examples.
  • Added detailed guides for authentication, templates, submissions, webhooks, and embedding.
  • Security documentation covering encryption, MFA, audit trails, BAA, and compliance standards.

​
Draft Persistence System

  • Builder auto-save: Template changes are automatically saved every 3 seconds with conflict detection. If another user modifies the same template, a conflict dialog appears with options to keep your changes, accept theirs, or merge.
  • Signing batch saves: Field submissions during signing are batched and sent together instead of one request per keystroke, reducing network traffic and improving performance on slow connections.
  • Offline resilience: Field changes are queued locally when the signer goes offline and automatically submitted when the connection is restored. An offline banner notifies the signer of their connection status.
  • Submission drafts: Submissions can now be saved as drafts before sending, allowing preparation of multi-submitter documents over multiple sessions.
  • Signature caching: Optional per-account setting to cache signature images locally in the browser, reducing friction for repeat signers. Configurable in Settings > Security.
  • New UI components: SaveStatusIndicator, DraftRecoveryDialog, OfflineBanner, and ConflictDialog.

​
March 2026

​
UI/UX Enhancements

  • Toast notifications: Replaced all alert() calls across 18 files with non-blocking toast notifications powered by vue-sonner. Supports success, error, warning, and info variants.
  • Form validation: Added real-time form validation with vee-validate and zod schemas to the Personalization settings and Send Modal. Validation errors appear inline below each field.
  • Token-aware textarea: The {{ autocomplete dropdown now appears in the Builder field configurator and Send Modal email body, showing available merge tokens (submitter name, email, document name, submission URL, etc.).
  • Spinner buttons: All action buttons that trigger async operations (save, send, delete) now show a loading spinner and are disabled during the request to prevent double submissions.
  • Confirm dialogs: Replaced all confirm() calls across 9 files with styled confirmation dialogs via HeadlessUI, with customizable title, message, and button labels.
  • New shared components: FieldError, SpinnerButton, ConfirmDialog, TokenAwareTextarea, TokenDropdown.

​
February 2026

​
HIPAA and SOC 2 Controls

  • Multi-Factor Authentication: TOTP-based MFA with authenticator app support, 8 single-use backup codes, and account-level enforcement that blocks admin access without MFA.
  • Encryption at rest: AES-256-GCM document encryption on all upload and output paths. Active Record Encryption for submitter PII fields (email, name, phone, IP, user agent, values, metadata).
  • Immutable audit trails: PostgreSQL trigger-protected audit entries with SHA-256 chain hashing and 7-year retention. Over 30 event types covering the full document lifecycle.
  • Business Associate Agreement: API and admin UI for accepting, checking, and revoking the HIPAA BAA.
  • Breach detection: Automated hourly service monitoring for privilege escalation, off-hours access, unusual login velocity, and failed MFA patterns.

​
Security Infrastructure Hardening

  • Session management: Server-side sessions via Redis in production with 30-minute inactivity timeout and instant invalidation capability.
  • Key management: Centralized EncryptionKeys module with ENV-based keys, HKDF derivation fallback, and key rotation support for all encryption layers.
  • Account-level MFA enforcement: Setting that requires all users in an account to enable MFA before accessing the admin panel.
  • Admin IP allowlisting: CIDR-based IP restrictions with lockout prevention and audit logging for blocked requests.
  • Enhanced logging: Structured request logging via lograge with user role and MFA status. Security Events API for querying authentication and access events.
  • API token scopes: Granular permissions on API tokens restricting access to specific endpoint groups.
  • Content Security Policy: Nonce-based CSP headers replacing unsafe-inline for script execution.
  • Template versioning: Templates now track version history, enabling rollback and change comparison.

​
AI Document Analysis

  • Intelligent field detection and placement suggestions for uploaded documents.

​
Document Thumbnails

  • Auto-generated page thumbnails for templates using pdftoppm from poppler-utils.
  • Served via GET /api/templates/:id/documents/thumbnail.
  • Manual regeneration available via POST /api/templates/:id/documents/generate_thumbnail.
  • Transparent handling of encrypted documents (decrypt to temp file before processing).

​
January 2026

​
Core Platform Launch

  • Templates: Create reusable document templates from PDF, DOCX, or HTML files. Define fields (text, signature, date, checkbox, initials, image, stamp, radio, select, number, phone, cells) with a drag-and-drop builder.
  • Submissions: Send templates to recipients for signing. Support for sequential and parallel signing workflows with configurable submitter order.
  • Signing experience: Mobile-optimized signing page at /s/:slug with multiple signing modes (normal, review and sign, confirmation modal, auto-scroll signature). Start screen customization with optional custom title and message.
  • Webhooks: 14 event types with HMAC-SHA256 signed payloads and SSRF protection. Configurable per-account webhook endpoints.
  • Embedding: Three integration approaches for embedding signing into your application (iframe, redirect, API-driven).
  • API: RESTful JSON API for templates, submissions, submitters, and documents with cursor-based pagination and token authentication.
  • Mobile optimization: Responsive design with hamburger menu, card-based submission lists, and optimized signing layout for phones and tablets.
  • One-click signing: Confirmation modal flow with auto-generated signatures for streamlined signing experiences.