You can now use our Document Analysis endpoint to extract and check data for a Business Registration Certificate. For now we only support the French Document called : Avis de situation.

To request a new Document Analysis for a business_registration_certificate document simply specify :

  • "type" : "company_certificate"

To check whether a person appears in the legal representatives extracted from the KBIS, you can optionally add :

  • checks[legal_representatives][0][first_name]
  • checks[legal_representatives][0][last_name]

In addition to those checks, we also use the issuance_date of the document to check whether the document is older then 3 months.

We improved our Consumption endpoints to include verifications add-ons, enabling you to track the consumption of all verification products.

This endpoint now returns all purchased verification add-ons for the current subscription period, including their consumed quantity since the start of the period.

You can also filter results using 9 new add-on values, covering all verification services.


This endpoint returns the aggregated Consumption of your verification products over a given period.

To help distinguish between different verification services, the response now includes a new field: verification_type, allowing you to identify which verification generated each Consumption entry.

For more information on consumption, you can consult our dedicated guide.

Previous validation rules for the first_name, last_name and legal person nameparameters could lead to situations where the verification remained stuck in a pending status.

To address this, we’ve introduced new validation rules for the following endpoints:

Updated validation rules

  • first_name and last_name:
^[('|’)]?[\d\p{L}\p{M}+][-\d\p{L}\p{M}+.'’ ]*$
  • legal_person name(only for the POST /verifications/bank_accounts) : maximum length of 128 characters

Impact of this change

Any verification request not complying with the new rules will now return a 400 Bad Request error.

We recommend reviewing your current integration to ensure compliance with the updated validation rules.

We have added three endpoints to retrieve your Consumption records in JSON. These complement the existing aggregated Consumption endpoint and expose the same level of detail currently available in the app’s CSV export, so you can see exactly for which Signature Request, Signer, or Document services were consumed, and when.

Availability: Production only (no consumption is recorded in Sandbox).

You can now change a Signer’s authentication mode after activation, as long as the Signature Request’s signature_level is Simple eSignature (electronic_signature), and the Signer is in status initiated or notified. This capability does not apply to Advanced or Qualified eSignatures (AES/QES).

If you modify the OTP mode while the Signer is on the authentication step, any code already sent is invalidated, and the new method applies.

For more information on the authentication, you can consult our dedicated guide.



You can now use our Document Analysis endpoint endpoint to extract and check data for KBIS documents.

To request a new Document Analysis from a KBIS document simply specify :

  • "type" : "company_certificate"

To check whether a person appears in the legal representatives extracted from the KBIS, you can optionally add :

  • checks[legal_representatives][0][first_name]
  • checks[legal_representatives][0][last_name]

In addition to those checks, we use the issuance date of the document to check whether the document is older then 3 months which is the validity period for a KBIS document.

To help you better understand the results of those checks we are adding status codes to the Document Analysis endpoint (more details here).


You can now control what appears inside a Signature Field with the new display parameter.

Set display.layout to detailed to add the Signer’s full name, email, and signature date directly within the Signature Field.

When detailed, you can personalize the date and time format.

Available on Field creation in POST /signature_requests/{signatureRequestId}/documents/{documentId}/fields (see API reference).

We have added a new UNKNOWN error reason to the list of QES identification errors to improve our resilience system with our provider.

  • This error is returned when an inconsistency occurs with our identity provider — for example, due to a breaking change in the managed error codes, or when an unexpected empty value is received.

More details about QES errors are available in our documentation here.

You can now verify whether a bank account belongs to a given personal account holder by comparing their name with the one retrieved from the bank.

To use this feature, provide the first_name and last_name fields when calling the endpoint [POST /verifications/bank_account_connections].

Yousign automatically compares these values with the bank account holder’s name and returns a failed status if the match is below the minimum acceptable level.

For more details about comparison rules and match levels, please refer to our dedicated guide.