Verified

Stricter Validation Safeguards for the Verified API

Updated

To enhance platform reliability, prevent downstream signing failures, and enforce strict data compliance, the Verified API is introducing stricter request payload safeguards.

Previously, certain malformed, partial, or missing payload fields were handled with loose server-side fallbacks. Under these updated safeguards, API endpoints that create, invite, or update envelope recipients will perform strict schema validation and immediately throw HTTP 400 Bad Request validation errors if the submitted payload violates the rules outlined below.

👥 Who Is Impacted?

  • Developers & Technical Integrators: Anyone sending automated requests to the Verified REST API.

  • Systems Administrators: Teams managing CRM, ERP, or custom portal integrations that generate signing requests automatically.

1. General Recipient Validation Rules (Creating / Adding Recipients)

When submitting payloads to create an envelope or add a recipient, all of the following parameters are strictly enforced:

FieldRequirementValidation Rules
givenNameMandatoryString; cannot be empty; must contain at least one valid alphabetical character.
familyNameMandatoryString; cannot be empty; must contain at least one valid alphabetical character.
emailMandatoryString; cannot be empty; must adhere to standard RFC email syntax (e.g., user@domain.com).
signingMethodMandatoryString; cannot be empty; must contain at least one character specifying an active signing method.
notificationMethodOptionalAccepts only "sms" or "email". If omitted, defaults to "email".
telephoneConditional

Mandatory if notificationMethod is "sms" or if the recipient sms flag is set to true. Must contain between 7 and 14 digits.

Regex: ^[0-9]{7,14}$

2. Secure Identification & SSN Validation

When sending envelopes that require recipient pre-authentication or electronic ID (eID) verification, the platform enforces conditional validation across secure, bank, and ssn.

The secure & bank Dependency

  • The secure flag is optional and defaults to false.

  • If secure is set to true, the bank field becomes mandatory.

When is ssn Required?

The bank field designates the identity verification provider or national authentication scheme. The platform evaluates ssn requirements as follows:

  • Exempt Providers (No SSN Required): If bank is set to "passport-reader" or "mobiilivarmenne", the ssn field is not required.

  • All Other Providers: The ssn field is mandatory and will be validated against national formatting standards.

3. Country Determination & National SSN Regex Patterns

To validate the ssn string, the API must determine the recipient's target country:

  1. Freja & ZealiD: If bank is set to "freja" or "zealid", the country is resolved from the secureProvider.country property.

  2. Direct Country Banks: For all other values, the bank parameter itself represents the two-letter ISO country code (e.g., bank: "se" maps to Sweden).

Once the country is resolved, the ssn string must conform to the corresponding regular expression:

CountryCodeFormat / Validation RegexDescription
Swedense^[0-9]{12}$Exactly 12 digits (YYYYMMDDXXXX)
Norwayno^[0-9]{11}$Exactly 11 digits
Estoniaee^[0-9]{11}$Exactly 11 digits
Lithuanialt^[0-9]{11}$Exactly 11 digits
Denmarkdk^[0-9]{10}$Exactly 10 digits (DDMMYYXXXX)
Belgiumbe^[0-9]{10}$Exactly 10 digits
Finlandfi^[0-9A-Z\-]{11}$11 characters (digits, uppercase letters, hyphen)
Serbiars^[0-9]{13}$Exactly 13 digits
Latvialv^[0-9]{6}(-?)[0-9]{5}$6 digits, optional hyphen, 5 digits
Portugalpt^.*$Any non-empty string

Danish Nets Fallback Exception

If the resolved country code is not listed in the table above, the API executes a fallback check:

  • The system inspects the roles array of objects.

  • If any object within roles contains the property additionalModel.signingMethod equal to "nets-esign-dk", SSN format validation is bypassed.

  • If this check returns false, the API request will fail immediately, as the platform cannot validate the SSN for that provider.

4. Recipient Update Validations (Editing Recipients)

When issuing requests to modify an existing recipient on an ongoing envelope:

  • notificationMethod accepts only "sms" or "email". If omitted from the update payload, it defaults to "email".

  • If updating phone or identity fields, the same formatting rules and regex constraints detailed above apply.

5. Deployment Timeline & Action Items

⚠️ Action Required for Development Teams:

Review your integration payloads and client-side form validation immediately to ensure all outbound API requests comply with these rules.

  • Status & Notifications: This update will roll out to production environments following a final deployment window. Please subscribe to our official status page at status.verified.io to receive maintenance windows, release schedules, and changelog announcements.

Guide tagged with: api
warning Warning.