Changelog
API
Envelope Branding
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.
API
Customization Updates for Checkboxes and Text Inputs
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:
API
New Way to Upload Files to SignatureAPI
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.
API
HIPAA Compliance Now Available in SignatureAPI
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.
API
Hungarian Language Support Added
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!
Power Automate
Power Automate Connector Is Generally Available
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.
API
Required Checkboxes in Signing Ceremonies
Checkbox places in SignatureAPI now support a new requirement
attribute. 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.
API
Accent Color in Embedded Ceremony
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.
API
Recipient Name & Email Places
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
):
Learn more in the docs:
API
Email Code Authentication
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:
For more details, see Email Code Authentication.
API
Short Ceremony URLs
You can now request a shorter ceremony URL when creating a ceremony for a recipient. This makes it easier to share signing links in space-constrained channels such as SMS or push notifications.
To use this feature, include the optional url_variant
property in your ceremony creation request. It accepts two values:
standard
(default): The full-length URL as before.short
: A condensed URL optimized for limited space.
This works seamlessly with custom authentication. Authenticate your recipient and obtain a short ceremony URL that you can send using SMS services like Twilio.
For example, to create a ceremony with a short URL:
The response will include the shortened URL in the url
field:
For more details on ceremony creation and custom authentication, see Create a Ceremony and Custom Authentication.
This feature is fully backward compatible and does not affect existing integrations using the standard ceremony URL.
API
Checkbox Place
We have added support for Checkbox Places in SignatureAPI. You can now define optional checkbox fields in your documents that recipients may check during the signing ceremony.
Two checkbox symbols are available: ✓ check
and ✗ xmark
. Use the symbol
property to specify which one to display when creating a checkbox place.
Checkbox values are captured and stored in the envelope’s captures
object, allowing you to retrieve whether the box was checked (true
) or left unchecked (false
).
Define a checkbox place in the document’s places
array like this:
For more details on checkbox places, see the Place Object documentation.
API
Signature Options
We’ve added a new signature_options
property to the recipient object. This lets you explicitly control which signature types a recipient can use during the ceremony.
The property accepts an array with the values drawn
and/or typed
. The first item in the array determines the signature option shown first to the recipient.
By default, signature_options
is set to ["typed","drawn"]
, so recipients see the type signature option first, followed by the drawn signature.
If you want recipients to only draw their signatures, set the array to ["drawn"]
. In this case, the typed option will not be available.
Here’s an example of a recipient configured to allow drawn signatures first, then typed signatures:
And here’s a recipient forced to draw their signature with no typed option:
This feature is fully backward compatible. If omitted, the default applies.
For more details, see the Recipients object in the documentation.
API
Recipient Released Event
We’ve added a new event type: recipient.released
. This event triggers when a recipient’s status changes from awaiting
to pending
, indicating they are ready to be sent a signing request.
This event is useful for automating multi-step signature workflows where you manually control when to send the signing request by creating a ceremony for the recipient. Receiving a recipient.released
event lets your system know it’s time to create the ceremony and initiate the signing process.
Example webhook payload snippet:
You can subscribe to this event type when configuring webhooks via the Dashboard or API.
This feature is fully backward compatible and supports advanced workflows where sending signing requests is controlled programmatically. For more details, see the Event Types documentation and Webhooks guide.