📇 Verifications: phone & email required for CURP-based requests

New — phone and email are now documented as required contact fields when creating verifications for individuals (POST /verifications and POST /verifications/bulk); the ReadMe "Try it" and generated SDKs will ask for them by default.
New — phone and email can now be enforced server-side for CURP-based verifications: requests missing them return explicit validation errors. RFC-based business verifications are not affected.
Improved — sandbox CURP flows always require phone and email for individuals, ensuring new integrations are built with contact data from day one; bulk requests reject only the offending items and continue processing the rest.

⚙️ What Changes

In the OpenAPI schema (VerificationRequest), phone and email are now marked as required alongside identifier.
Field and endpoint descriptions clarify that these contact fields are required for 18-character CURP identifiers (individuals) but not for 12-character RFC identifiers (businesses).
The Getting Started verifications guide and sandbox docs now highlight contact fields, and sandbox examples include working test values.

Enforcement is being rolled out gradually, account by account. Once active for your account, CURP-based requests missing phone and/or email are rejected with a validation error.
For POST /verifications, missing required fields on CURP-based requests yield 422 validation_error responses with clear messages like "phone is required for this account; email is required for this account".
For POST /verifications/bulk, validation happens per item: invalid CURP items are marked with status="error" and status_code such as missing_phone_email or missing_email, while other items (including RFC-based businesses) proceed normally.
Phone numbers are validated in E.164 format and emails as proper email addresses, returning 400 validation_error if malformed, even when enforcement is not yet active for your account.

If you are building or updating a BDI integration, send both phone and email for all CURP-based verifications and treat them as required in your own validation.
Existing production accounts keep the previous behavior for now; we will contact you before enforcement is enabled for your account.