💳 Per-verification billing, webhook event selection and new invoice fields

• Changed — Billable usage counted per successful verification — Starting with October usage, billable requests are counted per successful verification attempt instead of per unique CURP per month. If you successfully verify the same person three times in a month, all three now appear in your usage totals and invoices.
• Improved — Webhook event selection in the Console — In Developers → Webhooks you can now choose whether each webhook subscribes to verification.completed and/or export.completed when you create or edit it, and the detail view shows which events are enabled.
• Improved — New invoice fields: job tenure and bank accounts — GET /invoices/{identifier} now returns the employer-declared job_tenure and the payroll deposit account (bank, bank_account) on payroll invoices, plus the payer and beneficiary bank accounts in payment_info for payment (pago) invoices.

💳 Billable counts per successful verification

Usage and billing are moving from a "unique CURPs per month" model to a "per successful verification" model:

• Previously, if you successfully verified the same CURP multiple times in a month, those repeated checks were deduplicated: only one billable request per CURP per month appeared in your usage totals.
• Starting with October usage, each successful verification attempt is billable, even when the same CURP is verified multiple times in the same month.

This makes usage simpler to reason about: one successful verification = one billable request.

🔔 Webhook events in the Console

In the client Console under Developers → Webhooks:

• When creating or editing a webhook, you can now explicitly select which events it should receive: verification.completed and/or export.completed.
• At least one event must be selected; attempts to save with none selected are rejected by the API.
• The webhook detail view now shows the list of subscribed events, so you can confirm at a glance what each webhook will receive.

Existing API integrations that call POST /webhooks or PATCH /webhooks/{id} continue to work; the Console now sits on top of the same events field those endpoints already accept.

🧾 New invoice fields

GET /invoices/{identifier} adds optional fields taken directly from the CFDI. They are null when the source invoice doesn't carry them; nothing else in the response changes.

Payroll (nomina) invoices

• job_tenure — tenure with the employer as declared by the employer, as an ISO-8601 duration (e.g. P23W, P2Y3M). Reported, not verified — and not the same as the profile-level tenure.
• bank_account — the account or CLABE the payroll was deposited to (10 to 18 digits).
• bank — the bank of that account, as the SAT c_Banco code. Only sent when the account is not a CLABE, since a CLABE already encodes the bank in its first three digits.

Payment (pago) invoices — inside each payment_info item (returned with include_payment_info=true):

• payer_issuer_rfc and payer_account_number — RFC of the bank the payment was sent from, and the originating account.
• beneficiary_issuer_rfc and beneficiary_account_number — RFC of the bank that received the payment, and the receiving account.

Exports: the invoices.csv file in exports gains three columns — job_tenure, bank and bank_account (24 → 27 columns). If your integration reads the CSV by column position instead of by header name, update it before your next export. The payment fields are not included in the CSV.

See the Invoices reference in the developer docs for examples.