Notes for Release 4.46

Over the past weeks we have been working on improvements to Cellosign platform. In this post you can see a list of what has been changed, updated, and/or what bugs have been fixed.

Release rollout schedule

Stage environment: Scheduled for release on: 11/08/2026

Production & Pre-Production Environments: Scheduled for release on: 23/08/2026

Enhancements

Optional Data & Attachments on the Expiry Webhook

The Session Expired webhook (WHEF_SESSION_EXPIRED) can now optionally deliver the recipient’s form data and uploaded attachments — so you can capture the latest state of a form even when it expired without being submitted.

What’s new

Previously this webhook only told you that a session expired — it carried the event and basic session metadata, but none of the data the recipient had entered. If a form expired before being submitted, whatever the recipient had typed was lost to your integration.

Now you can choose to capture the latest state of an abandoned form — the entered field values and any uploaded files — so you can follow up, re-send, pre-fill, or audit drop-off.

Three new switches

Configured per webhook, shown only for the Session Expired webhook. All default off.

• Include data: Sends the form field data the recipient entered.
• Include paragraph fields When Include data is on, also sends read-only paragraph fields. Off → stripped.
• Include attachments Sends uploaded files / images. The signed document is never included.

Dependency.Include paragraph fields only applies when Include data is on. While data is off, the paragraph switch is disabled. Turning data on enables the paragraph switch but leaves it off until you turn it on explicitly.

Nothing changes unless you opt in

Every existing Session Expired webhook keeps sending exactly the same payload as before. With all switches off, the body is byte-for-byte identical to today’s — no data, no attachments, no signed document. There is no data migration, and webhooks created before this change are treated as “off”.

Restrict API token access by account type

Organizations can now control whether human user accounts are permitted to use the API at all — keeping API access limited to dedicated service accounts.

Previously, any account (including a regular user account, i.e. an agent) could generate an API access token and call API v3. There was no way to reserve API usage for service accounts only.

A new Cellosign Support–managed tariff option now governs this. When it is OFF (false), only service accounts may use API tokens; user accounts may not.

No change for active organizations: This restriction is not applied automatically. Existing organizations continue to work exactly as before — nothing changes unless you ask for it. The restriction is enabled on request, based on your own security requirements.

Configured by Cellosign Support only: There is no self-service setup page for this option. Customers cannot view or change it themselves — it is configured exclusively by the Cellosign Support team on your behalf.

Why this matters:

Separating API usage between service accounts and user accounts lets an organization ensure the API is called only by controlled, purpose-built service accounts — not by individual people’s user accounts.

When the flag is disabled (default)

• User interface: the API token section is not displayed in the user settings screen for user accounts. Service accounts are unaffected and still see it.
• API v3 enforcement: on every API v3 call, the token’s account is checked:
  • Token belongs to a user account → request is rejected with HTTP 403 Forbidden and the message: “Only service accounts are able to access this resource.”
  • Token belongs to a service account → request proceeds normally.

When the flag is enabled (true)

• User interface: the API token generation option is shown for user accounts.
• API v3 enforcement: user-account tokens are accepted on API v3, alongside service accounts.

Bug fixes

* Client forms accessibility bugs

Security

• Security patches and CVEs

Maintenance

N/A