Notes for Release 4.45

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: 27/07/2026

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

Enhancements

Keep sensitive documents out of email

You can now turn off the automatic result email sent to clients on a per-template basis. Previously, whenever a session was completed, the system always emailed a copy of the signed result to the client. There was no way to switch this off.

A new toggle, “Send result email to clients”, now appears in each template’s message settings. It is ON by default, so existing templates behave exactly as before. When you switch it OFF, the client result / copy email is no longer sent for sessions created from that template.

Why this matters: Health-data and privacy regulations often prohibit sending sensitive personal or medical documents over email. This control lets you use the product for regulated workflows without emailing sensitive results to signers.

A few things stay the same by design:

• Invitation emails (the links you send so a client can open and sign), reminders are not affected by this toggle.
• Workflow (BPMN) steps that are explicitly configured to email a client will still send — those are intentional notifications and bypass the switch.
• Agent emails are governed by a separate project setting

Read here the full guide for compliance

Project-Level Custom CSS

You can now define custom CSS at the project level, in the Brand section of your project configuration. Previously, custom CSS could only be set per template — meaning the same styling had to be pasted into every template individually.

1. Project-level Custom CSS field in the Brand section. Set it once and it applies to every form in the project.
2. Smart cascade: if a template has its own custom CSS, that template keeps using its own CSS. Templates without custom CSS automatically inherit the project-level CSS.
3. Audit trail: every change to your project-level CSS is recorded in the audit log (who changed it and when).
4. Clearer guidance: the CSS editor now shows expanded disclaimers about external images, accessibility, unsupported CSS errors, and cross-device/browser testing.

How the cascade works

Template CSS	Project CSS	Applied to the form
Set	Set	Template CSS
Set	Empty	Template CSS
Empty	Set	Project CSS
Empty	Empty	Default styling (no custom CSS)

Template CSS always wins — there is no merging.

New identity field in webhook recipient object

The recipient object in all event webhooks (WHEF_*) and in the archive webhook (WHP_ARCHIVE) now includes an additional field: identity.

In signer or a multi-signer processes, this lets your system attribute each webhook callback to a specific end user directly — without a follow-up call to the session data API. .

"recipient": {
  "id": 1,
  "name": "client",
  "identity": "550e8400-e29b-41d4-a716-446655440000"
}

The field is always present. When no identity is configured for the signer, the value is null:

"recipient": { "id": 1, "name": "client", "identity": null }

How identity is captured?

The user identity value is set at creation time, through one of three entry points. It is never set by the webhook itself — the webhook only reads what was already recorded.

BPMN process template

The designer sets role identity on the recipient role — either a static value or a reference to a process variable (e.g., a field from the initiation payload, or from a borrowers array so each recipient in a group gets their own value).

Session API

A single session created via POST /api/v3/{project}/session/ — the caller passes recipient.identity in the request body.

Workflow API

A multi-signer workflow created via POST /api/v3/{project}/workflow/ — the caller passes recipients[].identity, one value per signer.

Key behaviors

The field is optional and nullable in all three paths — if nothing is provided, it’s stored as NULL and serialized as null in the webhook, with no error anywhere in the dispatch path. Each signer’s session carries its own independent value, so in a 3-signer mortgage flow each webhook reports its own signer only. The one exception: when require_enduser_sso is true, a missing identity is rejected at session creation (pre-existing SSO guard, unrelated to the webhook change). In SSO flows the identity can also arrive via the SAML assertion.

Action required

This is an additive change — no existing field is removed, renamed, or retyped. However: if your integration validates webhook payloads against a strict JSON schema (no additional properties), update your schema to allow the new identity field before the release date. XML webhook consumers will see a new <identity> element inside <recipient>; verify you do not enforce strict DTD validation.

Data privacy note

Depending on your process configuration, identity may contain personally identifiable information (e.g., a national ID or customer GUID). Apply the same logging and retention practices you already use for the labels payload.

Bug fixes

* Client forms accessibility bugs

Security

• Security patches and CVEs

Maintenance

N/A