To simplify the experience across all our verification products, we’ve redesigned several aspects of the solution for:

  • Video identity verification
  • Document identity verification
  • Bank account verification

This redesign includes renamed endpoints and parameters, richer response payloads, new statuses and status codes, and updated Webhook events.

What is changing?

Endpoint route naming

We've updated the naming of several endpoints to group them under a more consistent namespace:

BeforeAfter
POST /id_document_verificationsPOST /verifications/identity_documents
GET /bank_account_verifications/{id}GET /verifications/bank_accounts/{id}

Endpoint parameter names

Some parameter names have been harmonized across verification types:

BeforeAfter
legal_entity_namelegal_person
first name and last namenatural_person

Response format changes

We’ve enriched all the POST and GET endpoints by providing more information in the responses.

For example, before, only the id was returned when initiating a verification.

Now you’ll also receive:

  • workspace_id
  • created_at, updated_at
  • status
  • status_codes
  • data_anonymized
  • data

This gives you better visibility into the lifecycle of a verification.


New status & status codes

  • New status

We’re aligning the former approved and declined statuses across all verification types:

BeforeAfter
approvedverified
declinedfailed
  • New status codes

New prefixed status codes help identify the type of verification:

VerificationBeforeAfter
Video identity verification1201IDVV_1201
Document identity verification1103IDDV_1103
Bank account verification1602BAV_1602

Webhook

Event names have been updated for clarity and alignment:

VerificationBeforeAfter
Video identity verificationvideo_identity_verification.doneverification.identity_video.done
Document identity verificationid_document_verification.doneverification.identity_document.done
Bank account verificationbank_account_verification.doneverification.bank_account.done

The Webhook payloads have also been improved for better traceability.


📘 For full details on all changes, including routes, parameters, payload examples, check out our updated guides:

We have added three new properties to text, checkbox, and radiogroup Fields:

  • name: Set a readable name to help identify and manage Fields. This won’t be visible to recipients.
  • default_value: Pre-fill Fields with known information.
  • read_only: Lock pre-filled Fields to prevent edits by Signers.

For more details, please refer to the API Reference.

The Qualified Electronic Seal is now available through the Yousign API!
It allows companies (legal persons) to seal documents without requiring the actions linked to a signature process.
It prevent the risk of fraud and proves document authenticity and integrity.
In addition to simpler use cases, we advise using this seal level in particular for electronic invoicing and notary deeds.

Please reach out to your customer representative to activate this product on your account.

Guide
https://developers.yousign.com/docs/qualified-electronic-seal

Endpoint
https://developers.yousign.com/reference/post-electronic-seals

We've enhanced Text to Copy Consent by providing real-time error highlighting. When the Signer makes a mistake, the incorrect character will be highlighted in red. Once correct, the text will turn green, making it easier to identify and fix errors.

Additionally, input is now restricted to the exact number of characters specified in the instruction, helping Signers avoid mistakes and enter the text accurately.

For more details about this feature, please refer to our guide.

You can now manage how your Signature Requests are embedded in your applications or websites directly from the Yousign interface. A new iFraming settings page is available in your Application, under API > iFraming.

From there, you can:

  • Choose between three security modes (not authorized, authorized domains only, origin referer always authorized)
  • Add and manage authorized domains for embedding Signature Requests

💡

Any previous settings configured with our Support Team remain unchanged and continue to apply.


For more details, refer to our guide.

Previously, only one first name from a Signer’s list of given names was accepted for identity validation during the Qualified Electronic Signature (QES) flow. For example, if a Signer’s ID document lists "Eve Louise Coralie", only one of these names —"Eve", "Louise", or "Coralie" — needs to be used.

Starting today, we now accept any combination of all given names as a valid first name for a Signer! This means "Eve Louise Coralie" can now be used as a valid first name for the identification phase in the QES flow.

For more details, please refer to our dedicated API guide.

It is now possible to disable the email notification sent to Followers when a Signature Request is activated. This can be configured within the Custom Experience using the disabled.notifications parameter.

To disable this notification, specify the option follower.activated in the disabled.notifications parameter when using the following endpoints:

For more details, please refer to our dedicated guide.