[javorosas]

Creating a customer with a generic RFC accepts an address without a postal code, but the documented input currently requires one when the country is Mexico. The contract now accepts an omitted, null, or empty postal code and describes the permitted fiscal regime and default invoice use.

The Spanish and English specifications and generated type fixtures agree. OpenAPI checks pass for both locales.

[Copilot]

🟡 Changes recommended

Both OpenAPI schemas still allow invalid foreign addresses by dropping the required non-Mex three-character country constraints, leaving active correctness issues.

2 open issues

• Restore foreign address country constraints · New
• Restore foreign address country constraints · New

What changed in this PR

This pull request updates the bilingual OpenAPI contract for generic RFC customer creation, allowing Mexican addresses to omit, null, or use an empty postal code while documenting fiscal regime and invoice-use rules. The current schema changes also broaden foreign-country and shared invoice-use validation beyond the generic contract.

Changes:

• Updated Spanish and English generic customer schemas for optional postal codes.
• Added fiscal regime 616 and default invoice use S01 validation cases.
• Extended OpenAPI validation and generated TypeScript fixtures.
• Preserved review findings concerning lost foreign-country constraints and unintended nullable values in shared schemas.

File	Description
website/​test/​openapi-types.fixture.txt	Adds generated TypeScript fixture coverage for the updated generic customer inputs.
website/​scripts/​check-openapi.mjs	Adds validation cases for postal codes, fiscal regimes, and invoice uses.
website/​openapi_v2.yaml	Updates the Spanish generic customer contract and address validation rules.
website/​openapi_v2.en.yaml	Mirrors the generic customer contract changes in English.

_{Review effort: Lite}