Improved

📱 Phone required by default from September 28 — email now always optional


  • Improvedemail is now always optional when creating verifications. It can no longer be set as required for any account: POST /verifications and POST /verifications/bulk accept requests without an email, and validation errors and bulk rejection codes no longer reference the email. You can still send email optionally to improve identity matching.
  • Heads-up — from September 28, 2026, phone becomes required by default for CURP-based verifications created through the API, for compliance reasons. Requests without a phone will be rejected from that date on.
  • Improved — Console: creating a verification now always asks for CURP + phone, both mandatory, with the +52 country code pre-filled and the format validated before submit.
  • New — Console: the invoice list now shows whether each CFDI is an income or an expense for the person you queried, and payroll invoices that look like a severance payment are flagged.
  • Improved — Console: every page now has a help footer with [email protected]the single channel for support. Requests sent over WhatsApp or directly to someone on the team get redirected there, so write to [email protected] from the start.

⚙️ What Changes

email is never a required field

  • The option to require email per account has been removed — there is no longer any configuration in which the email is mandatory. Accounts that had it enabled were migrated back to optional.
  • 422 validation_error messages and per-item bulk rejection codes now only ever refer to the phone; the email is never reported as missing.
  • email is still accepted and still used to improve identity matching, so keep sending it when you have it.

phone required by default on September 28, 2026

  • Phone enforcement has been rolling out account by account. On September 28, 2026 it becomes the default for every account: CURP-based requests to POST /verifications and POST /verifications/bulk that arrive without a phone will be rejected with a 422 validation_error.
  • RFC-based business verifications (12-character identifiers) are not affected.
  • Phone numbers must be in E.164 format (e.g. +525512345678). Malformed numbers already return 400 validation_error today, independently of the deadline.

Console

  • Verification creation — the form asks for CURP and phone, both required, with +52 pre-filled and the phone format validated (clear error message if it is invalid). The same flow now applies to every account.
  • Income vs expense on invoices — the invoice list adds an explicit Ingreso / Gasto badge computed from the role of the person on the CFDI (issuer vs receiver), instead of only showing the CFDI type from the issuer's point of view. Payroll received by the person counts as income; an "Ingreso" CFDI where the person is the receiver is shown as an expense. The filter follows the same distinction, and the original CFDI type stays visible.
  • Severance signal on payroll invoices — payroll CFDIs carrying SAT percepción codes for separation payments or indemnities are badged as a likely finiquito/liquidación, with an amount floor so symbolic stamps are not flagged. This is available in the Console only for now; it is not exposed in the API yet.
  • Help footer — all Console pages now show a help pill linking to [email protected]. This is the only way to reach support: messages sent over WhatsApp or to individual team members are redirected to that address. Writing to [email protected] gets your request tracked and prioritized automatically, with a clear history of the conversation, and answered by the team rather than depending on one person being available.

🛠️ Action Recommended

  • Before September 28, 2026 — make sure your integration sends phone in E.164 format for every CURP-based verification. This is the only breaking change coming in this release.
  • Stop treating email as a required field in your own validation, and drop any handling of an "email missing" rejection code on bulk requests.
  • No action needed for the Console changes — they are already live.