You can now retrieve an Audit Trail for Certified Identity Verification - PVID. This helps you access a verification summary and keep a record of the verification process when needed.

The audit trail is available via:

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

You can now restrict Document access per recipient within a single Signature Request. Excluded recipients cannot see the Document at all: it is not listed, not accessible, and not referenced in their signing experience. A Signer's electronic signature covers only the Documents visible to them.

By default, all recipients see all Documents; existing integrations require no changes.

New parameters on Document, Signer, and Approver endpoints:

  • excluded_signers and excluded_approvers (arrays of UUIDs) on POST /documents and PATCH /documents/{documentId}: define which Signers and Approvers cannot see a Document
  • excluded_documents (array of UUIDs) on POST /signers, PATCH /signers/{signerId}, POST /approvers, and PATCH /approvers/{approverId}: define which Documents a Signer or Approver cannot see

Available on Pro and Scale plans.

An organization admin must enable it first: Settings > Signature settings > Sender capabilities > Document visibility.

For full details, see the updated Document, Signer, and Approver guides.

To preserve signature integrity, QES (Qualified Electronic Signature) identifications are now invalidated 30 minutes after they are validated. If a Signer attempts to sign after this window, an error is triggered and the identification must be restarted. New webhook event: signer.identification_expired fired when a Signer's identification expires and the event is also tracked in the Signer's Activity feed.

  • Credits consumed for an expired identification are not refunded.
  • Wallet enrollment and previously enrolled wallets are not affected by this expiration rule.
  • This behavior is not available in Sandbox.

If you need any additional information about QES limitations, consult the dedicated guide here.

You can now analyze payslips with Document Analysis by using the initiation endpoint.
This helps you automate income and employment verification by extracting key payroll data from supported documents. Document Analysis will also automatically recognize and validate that the uploaded file is indeed a payslip. For the payslip document type, Document Analysis now extracts:

  • first_name
  • last_name
  • full_name
  • employer_name
  • pay_period_start_date
  • pay_period_end_date
  • net_pay
  • gross_pay
  • document_type

You can also send optional consistency-check parameters when creating the analysis:

  • first_name: checks that the provided first name matches the document
  • last_name: checks that the provided last name matches the document

To learn more, see the Document Analysis guide.

You can now enforce business rules when creating a Video Identity Verification. Configure the new parameters with the request endpoint POST /verifications/identity_videos (see API reference):

  • min_age - minimum accepted age
  • max_age - maximum accepted age
  • prohibited_countries - list of issuing countries to reject

These checks are available across all Video Identity Verification types: with or without face match, and Certified Identity verification. If a configured rule is not met, the verification returns a failed status with a dedicated status code. Please see the status code mapping on this page and learn how to configure these checks in the guide.

You can now provide four optional search fields when initiating a Company Verification with country_code set to DE. These help narrow the lookup when several companies share similar names:

  • zip_code — 5-digit Postleitzahl (e.g. 10115).
  • street — the company's street address.
  • city — the company's city.
  • register_court — the German Registergericht (commercial register court) handling the company. Pass the court name as a free-text string (e.g. Amtsgericht Berlin-Charlottenburg).

All four fields are optional and only accepted when country_code is DE.

Read the guide

You can now retrieve when each key action occurred in the lifecycle of a Signature Request, directly from the API.

New fields on Signature Request endpoints:

  • activated_at: when the Signature Request was activated and made available to recipients
  • completed_at: when all Signers signed, and all Approvers approved (i.e. the Signature Request reached done)
  • approved_at: when all Approvers approved (returns null if custom_recipient_order is enabled, or if no Approvers are configured)

New fields on Signer endpoints:

  • signed_at: when the Signer completed their signature

New fields on Approver endpoints:

  • approved_at: when the Approver approved the Signature Request

Related webhooks payloads now also contain those new fields.

Qualified Electronic Signature (QES) now supports multiple Signature Fields per Signer per Document. Previously, adding more than one QES Signature Field triggered a blocking error: this restriction has been removed.

Key behaviors to be aware of:

  • Single Signature: A single cryptographic Signature covers all signature images on the Document. This differs from SES and AES, but meets the legal requirement — one technical Signature is sufficient for a valid electronic signature.
  • Signature panel: With multiple QES Signature Fields converted directly into images, clicking a Signature Image in an external PDF reader will not open the signature panel directly. The panel is still accessible and of course the Signature remains valid.
  • Locked PDFs: Multiple QES Signature Fields are not supported on locked PDFs.

For full details, see the QES level specificities guide and the Signature Fields API reference.

You can now scope API keys to specific workspaces and benefit from a higher API key quota.

Workspace-scoped API keys [NEW]

API keys now support two types of scope:

  • organization: the key can access data across your entire Yousign organization.
  • workspace: the key can access data only for selected workspaces.

This is useful if you:

  • Manage multiple entities in separate workspaces, and want separate keys per entity to isolate access.
  • Want to apply least-privilege access for improved security

API key quota increased

  • Before: 5 active API keys per organization
  • Now: 200 active API keys per organization
📈

Need more API keys?

If you are on the Scale plan, we can increase your quota. Please contact the customer support.


To learn more, see our guide on API keys.

You can now define Custom Properties on Signature Requests (dropdown lists and free text) to categorize and track Signature Requests across your team. Properties are managed at organization level and optionally scoped to specific Workspaces.

Custom Properties can be created and managed via the new /custom_properties resource (see API reference).

To use them on Signature Requests, pass the new custom_properties parameter when calling POST /signature_requests or PATCH /signature_requests/{signatureRequestId}.

Property values are returned in GET /signature_requests and GET /signature_requests/{signatureRequestId} responses, and included in Signature Request Webhook events.

Two new filter parameters on the list endpoint (custom_property_value_id and custom_property_value) let you query Signature Requests by property values.

Available on Pro and Scale plans. For full details, see the Custom Properties guide.