Versionado

Revi usa versiones por fecha en la URL para la API pública:

/api/YYYY-MM/...

Versión recomendada:

/api/2026-10

La respuesta incluye:

Revi-Version: 2026-10

Política de versiones

Estas reglas son vinculantes. Determinan cuándo puede crearse una versión fechada nueva, qué significa su fecha y cuánto tiempo se mantiene.

1. La fecha es el mes en que la versión entra en vigor. YYYY-MM nombra el mes en que la versión empieza a servirse en producción, no el mes en que se escribió su código. Nunca se publica una versión con fecha futura lejana, ni se renombra a una fecha posterior una versión que ya se está sirviendo.
2. Los cambios aditivos se quedan dentro de la versión vigente. Endpoints nuevos, campos de petición opcionales nuevos, campos de respuesta nuevos, códigos de error nuevos y scopes nuevos se añaden a la versión fechada en vigor. No justifican una versión fechada nueva.
3. Solo un cambio que rompe compatibilidad justifica una versión nueva. Rompe compatibilidad: eliminar o renombrar un endpoint, campo o código de error; convertir en obligatorio un campo de petición opcional; estrechar el rango de valores aceptados; o cambiar el significado de un campo existente. Es decir, cualquier cosa que haga dejar de funcionar a un cliente existente correcto.
4. Ventana de soporte: al menos 24 meses tras publicarse una sucesora. El plazo se cuenta desde el mes en que la sucesora entra en vigor, nunca desde el mes en que se publicó la propia versión. Una versión sin sucesora no tiene fecha de caducidad.
5. Señalización. Las versiones deprecadas devuelven Deprecation: true; las que tienen retirada planificada devuelven Sunset; las retiradas devuelven 410 Gone.

Compatibilidad

La versión 2026-04 continúa disponible para integraciones existentes, sin redirecciones ni migración automática. 2026-10 es la versión recomendada y la que recibe las capacidades nuevas, incluidos el estado de origen de pedidos por conexión, la lectura de políticas de invitación, los eventos de auditoría y los backfills.