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:

// POST https://api.signatureapi.com/v1/recipients/{recipientId}/ceremonies

{
  "authentication": {
    "type": "custom",
    "provider": "ACME App",
    "data": {
        "correlation id": "a4f9e8b2-7c1d-4b2d-9a4b-e0c5d6f7a1b3",
        "session id": "se_88620999344"
    }
  },
  "url_variant": "short"
}

The response will include the shortened URL in the url field:

{
    //...
    "url": "https://sign.signatureapi.com/s/ZdxlxxxxxxxxxxsU",
    //...
}

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.

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:

{
  "key": "postal_address_delivery",
  "type": "checkbox",
  "symbol": "check",
  "recipient_key": "policy_holder"
}

For more details on checkbox places, see the Place Object documentation.

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:

{
  "type": "signer",
  "key": "client",
  "name": "Alice Smith",
  "email": "alice@example.com",
  "signature_options": ["drawn", "typed"]
}

And here’s a recipient forced to draw their signature with no typed option:

{
  "type": "signer",
  "key": "visitor",
  "name": "Bob Johnson",
  "email": "bob@example.com",
  "signature_options": ["drawn"]
}

This feature is fully backward compatible. If omitted, the default applies.

For more details, see the Recipients object in the documentation.

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:

{
  "id": "evt_xxxxxxxx",
  "type": "recipient.released",
  "timestamp": "2025-12-31T12:00:00.000Z",
  "data": {
    "envelope_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "object_id": "re_xxxxxxxxxxxxxx",
    "object_type": "recipient",
    "recipient_type": "signer"
  }
}

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.