🔄 Updates to POST /consents & /verifications

Several improvements shipped across POST /consents and POST /verifications — IPv6 support, a CURP-only identifier rule for individuals, and client-provided RFC for invoice extraction — plus three new Sandbox Business RFCs for end-to-end integration testing.

⚙️ What Changes

1. POST /consents — IPv6 ip_address now accepted

• The ip_address field now accepts both IPv4 and IPv6 addresses.
• Previously, IPv6 addresses (e.g. 2806:10ae:5:d0f0:3407:54b7:8f00:e027) were rejected with a validation error.
• No changes required for integrations already sending IPv4.

2. POST /verifications — CURP is now the sole identifier for individuals

• For individual subjects, only a valid 18-character CURP is accepted as identifier.
• Passing a 13-character individual RFC as identifier now returns a 400 validation error.
• Business identifiers (12-character RFC) are unaffected.
• Action required — if your integration sends an individual RFC as identifier, migrate to CURP before this change affects your requests.

3. POST /verifications — client-provided rfc is now used for invoice extraction

• The optional rfc field in POST /verifications was previously accepted but ignored. It is now validated and used.
• When rfc is provided and valid (chars 1–2 and 5–10 match the CURP), it is used directly for CFDI invoice extraction, bypassing the internal CURP → RFC conversion.
• When rfc is invalid or absent, the system falls back to the internal CURP → RFC conversion. The verification is never rejected due to an invalid rfc.
• Providing a correct RFC improves invoice retrieval coverage, especially for users whose RFC cannot be derived automatically.

4. Sandbox — three Business RFC fixtures for integration testing

Three fictional Business RFCs are now wired up in the sandbox environment and can be used for full end-to-end integration testing:

• MAC850314TX2 and CHA110207NK7 — happy path: POST /consents, POST /verifications, GET /business-profile/{identifier}, and GET /invoices/{rfc} all return expected fixtures, and the verification.completed webhook fires with data_available: true.
• AZT920901PR3 — no-data path: the webhook fires with data_available: false and GET endpoints return 404. Use this to validate your error-handling logic.

🛠️ Summary of Action Items