Versionado

La API versiona el contrato por fecha. La version forma parte de la ruta (/v1) y se identifica con una fecha de publicacion. Puedes fijar la version con la cabecera opcional X-Api-Version; si no la envias, se usa la version vigente.

Politica#

La version forma parte del contrato: un cambio incompatible se publica en una nueva version (nueva fecha), no dentro de la vigente.
Una version vigente solo recibe cambios compatibles: campos opcionales nuevos, endpoints nuevos y codigos documentados. Un integrador que ignora lo que no conoce no se rompe.
Un eventType de webhook desconocido se ignora sin detener el procesamiento.
Ventana de deprecacion: cuando una version se reemplaza, se anuncia aqui, se mantiene operativa durante el periodo de solapamiento y luego se retira. El anuncio y el retiro quedan fechados.

Version vigente#

Version	Fecha	Estado	Retiro
V1	2026-10-03	Actual	-

El calendario en formato de maquina esta en api-versions.json y el detalle de cambios en el Changelog.

Cabecera X-Api-Version#

Uso	Valor
Solicitud (opcional)	La fecha de la version deseada, p. ej. `2026-10-03`. Si se omite, se usa la vigente.
Respuesta (siempre)	La version del contrato que respondio.

Si envias una version que no existe o ya se retiro, la API responde 400 con codigo 306 (Errores). No la fijes a ciegas: lee la version resuelta en la respuesta.

Cabeceras de deprecacion (RFC 8594)#

Cuando una version entra en deprecacion, la respuesta puede incluir:

Deprecation: fecha en que la version quedo obsoleta.
Sunset: fecha en que la version dejara de responder.

Consumelas para planificar la migracion antes del retiro.

Cambios relevantes de V1#

No incluyas version ni formato en la Estructura del comprobante; si los envias, la API responde 422.
Toda emision se realiza como normal (1); no informes tipoEmision.
La cabecera del tipo de comprobante va en info.
Errores con forma estable codigo, mensaje y errores (solo validacion); la correlacion va en la cabecera X-Correlation-Id.