Recipients now support two new types: approver and preparer.

An approver reviews and approves documents without adding a signature. A preparer fills in document fields before the envelope reaches a signer. Both can interact with text inputs, checkboxes, and dropdowns, but cannot sign.

Use sequential routing so approvers and preparers act before signers.

Approver docs | Preparer docs

Two new place types are available for document fields.

Boxed text input (boxed_text_input) displays individual character boxes, suited for verification codes, ZIP codes, and similar structured data.

Dropdown (dropdown) lets recipients select from a predefined list of options. You can supply custom options or use a predefined set like us_states_names or world_countries_names.

Boxed text input docs | Dropdown docs

The envelope object now includes a snapshot_url property. It provides a URL to download a PDF of the envelope's current state, including documents and any signatures collected so far. Useful for monitoring in-progress envelopes without waiting for completion.

Envelope object docs

Two ceremony customization options are now available.

Redirect delay. The redirect_delay property controls how long the ceremony UI waits before redirecting after completion. Defaults to 3 seconds.

Email overrides. For email_link authentication, subject_override and message_override let you customize the invitation email subject and body per recipient.

Ceremony object docs | Redirect URL docs

Two new properties on the deliverable object give you more control over what gets generated.

included_documents specifies which documents from the envelope to include in the deliverable. Pass an array of document keys to generate a deliverable with only a subset instead of all documents.

name sets an identifier for the deliverable, useful for distinguishing between multiple deliverables on the same envelope.

Deliverable object docs | Create a deliverable

You can now configure a recipient’s ceremony directly within the envelope creation request by including a ceremony object on each recipient.

Previously, creating a ceremony with custom settings required a separate API call to POST /v1/recipients/{recipient_id}/ceremonies after the envelope was created. Now you can do it in one step.

{
    “title”: “Service Agreement”,
    “recipients”: [
        {
            “key”: “client”,
            “type”: “signer”,
            “name”: “Emily Johnson”,
            “email”: “emily@example.com”,
            “ceremony”: {
                “authentication”: [
                    {
                        “type”: “email_link”,
                        “subject_override”: “Please sign the Service Agreement”
                    }
                ],
                “redirect_url”: “https://example.com/done”,
                “redirect_delay”: 5
            }
        }
    ],
    //...
}

If ceremony is not provided, a ceremony with email_link authentication is created by default.

The previous ceremony_creation property is deprecated but continues to work for backward compatibility.

Create a ceremony docs | Ceremony object

Deliverables now support two types: standard and simple.

Standard (default) includes the signed documents and an audit log with a certificate of completion.

Simple includes only the signed documents, with no audit log pages in the PDF.

Both types are tamper-proof with a cryptographic seal for verification. You can create additional deliverables via the Create Deliverable endpoint and choose the type at that point.

Deliverable object docs | Standard deliverable | Simple deliverable

You can now download an envelope from the dashboard before it’s completed. The downloaded file includes any signatures and initials collected so far, along with all recipient-entered information up to that point—making it easy to track progress and verify what’s been completed.

Find the Download Current Version link on the envelope page in the dashboard, just under the envelope’s status.

We’ve added two new recipient event types—recipient.accessed and recipient.viewed—to give you better visibility into recipient activity during the signing process.

Use recipient.accessed to track when a recipient enters the signing ceremony. This event also includes the recipient’s IP address and user agent. Use recipient.viewed to track when the recipient has completed authentication (if any) and the documents are displayed.

We also now include a session_id on ceremony events, so you can correlate related ceremony activity across multiple events.

Learn more in the Recipient Events docs.

SignatureAPI is now SOC 2 type II compliant across all five Trust Service Criteria (TSCs), providing independent assurance that our controls are designed and operating effectively.

• Security – Protects systems and data from unauthorized access.

• Availability – Ensures the platform is reliable and available for use as committed.

• Processing Integrity – Confirms that API operations and signing workflows run accurately and as intended.

• Confidentiality – Safeguards customer data from unauthorized disclosure.

• Privacy – Governs how personal data is collected, used, retained, and protected.

Learn more about our SOC 2 compliance.

SignatureAPI now supports branding, letting you configure logos, accent colors, and email footers on a per-envelope basis. This makes it easier to match your company’s visual identity across the signing process.

Recipient-facing elements that can be branded include:

• The signing ceremony interface

• Emails such as signing requests and envelope completion notices to recipients

This update is backwards compatible, so existing workflows continue to function without modification. In addition, we’ve updated email templates to better support custom branding.

For more, see the Branding docs.

We’ve introduced new customization options for checkbox and text input fields in the signing ceremony, making it easier to tailor signing experiences to your recipients’ needs.

• Checkbox height: Adjust the visual height of checkboxes for better alignment with document layouts.

• Text Input Font Size: Set the font size for recipient-entered text to match your document’s style.

• Text Input Width: Define how wide the field displays during the signing ceremony, giving more flexibility for longer or shorter inputs.

These enhancements were built in response to customer feedback and are fully backwards compatible, ensuring existing templates and workflows remain unchanged.

For more details, check out our updated docs:

• Text Input Place

• Checkbox Place

We’ve added a new Uploads resource to SignatureAPI, making it easier than ever to bring files into the platform. Previously, working with files required two separate requests using the File resource. With Uploads, it’s now a single streamlined step—just send your file and immediately use it across the API.

Uploads can serve as source documents or templates and are compatible with other endpoints, such as document.url. Supported formats include PDF and DOCX, with a 5 MB maximum size. Uploads are designed for temporary use and automatically expire after 24 hours. For long-term storage, you can continue to manage files in your Dashboard’s Library.

While the legacy File resource remains supported for backward compatibility, Uploads is now the recommended method—developed directly in response to customer feedback.

SignatureAPI now supports HIPAA compliance for organizations working with protected health information (PHI).

HIPAA—the Health Insurance Portability and Accountability Act—is a U.S. law that safeguards sensitive health data. It applies to healthcare providers, insurers, and any third parties that handle PHI on their behalf (called business associates). If you’re in US healthcare or building tools for healthcare, HIPAA likely applies to you.

HIPAA mode must be enabled on your account, and Business Associate Agreements (BAAs) are signed upon request. If you handle PHI, contact us to get started. This update makes it easier to build secure, compliant e-signature flows for healthcare—and to do it right.

Learn more about HIPAA and SignatureAPI.

SignatureAPI now supports Hungarian (hu), enabling a fully localized experience for your Hungarian-speaking recipients. Emails, ceremony UI, and audit logs are all available in Hungarian. Set it as your default language in the dashboard or apply it per envelope using the language parameter in your API request.

Boldog automatizálást!

The Power Automate connector is now generally available. Based on feedback received during the preview period, we’ve made several improvements to stability and performance. The connector is now certified and fully supported for production use on Microsoft’s Power Automate platform.

No action is required for existing users.

Checkbox places in SignatureAPI now support a new requirementattribute. By default, checkboxes are optional, but setting requirement to required enforces that the signer must check the box before completing the ceremony—ideal for explicit consent or acceptance of terms.

This property is fully optional. Omitting it keeps the checkbox optional.

You can now customize the accent color of an embedded signing ceremony using the accent_color query parameter in the ceremony URL. This allows you to match the signing experience to your brand’s look and feel, improving trust and visual consistency.

The parameter accepts any valid hex color without the # prefix (e.g., 8e24aa). It gracefully falls back to the default blue if omitted.

For example, to set the accent color to purple:

https:​//sign.signatureapi.com/en/start?token=eyJhbGci...nn?accent_color=8e24aa

Here’s how the ceremony interface appears with your chosen accent color applied:

For more, see the Embedded Ceremonies Customization docs.

We’ve added two new place types to SignatureAPI: recipient_name and recipient_email. These let you dynamically insert the recipient’s name or email into a document using their recipient_key.

Just like signature places or text input places, you can position these using either fixed coordinates or placeholders. This is useful for auto-filling personalized details directly into contracts, agreements, and letters—no manual entry required.

For example, to insert a recipient’s name and email based on their key (client):

"documents": [
  {
    "places": [
      {
        "key": "client_name",
        "type": "recipient_name",
        "recipient_key": "client"
      },
      {
        "key": "client_email",
        "type": "recipient_email",
        "recipient_key": "client"
      }
    ]
  }
]

Learn more in the docs:

• Recipient Name Place

• Recipient Email Place

SignatureAPI now supports Email Code Authentication, giving you a new way to secure signing ceremonies while keeping control of how ceremony links are delivered.

Unlike traditional Email Link Authentication, this method sends recipients a 9-digit code via email, which they must enter to access the ceremony. It’s ideal if you’re delivering links through your own channels (like SMS or in-app notifications), or if recipients are in environments where email links may be filtered.

To use email code authentication, specify "type": "email_code" in the authentication array when creating a ceremony. The API will return a Ceremony URL that you can distribute through any channel you prefer.

This is the third supported authentication type alongside Email Link and Custom Authentication, and can be combined with either for additional verification.

Here’s how to enable it:

// POST /recipients/{recipient_id}/ceremony

{
  "authentication": [
    {
      "type": "email_code"
    }
  ],
  //...
}

For more details, see Email Code Authentication.