Control de versiones

En esta guía, se explica cómo la API de Merchant controla el control de versiones, las versiones y el ciclo de vida de sus diferentes versiones.

Esquema del control de versiones

La API de Merchant emplea una estrategia de control de versiones a nivel de la sub-API. Esto significa que cada API, por ejemplo, la API de Merchant, tendrá su propio ciclo de vida de versiones.

Formato y presentación del control de versiones

• Versiones secundarias estables de la API: Si una API secundaria está en una versión estable, todos sus métodos también lo están. Una versión secundaria estable de la API se representa como vX (por ejemplo, v1, v2). Estas son versiones principales listas para producción.

• Versiones alfa de sub-APIs: Si una sub-API está en versión alfa, todos sus métodos también lo están. Una versión alfa de la sub-API se representa como vXalpha (por ejemplo, v1alpha, v2alpha). Contienen funciones experimentales de acceso anticipado diseñadas para pruebas y una rápida iteración. Las versiones alfa no tienen garantía de estabilidad, no tienen una vida útil definida y se pueden cambiar o descontinuar con un período de aviso de 30 días.

Cambios en la versión

• Incrementos de versión principal (por ejemplo, de la versión 1 a la 2): Indican cambios rotundos e incompatibles con versiones anteriores, que requieren la acción del desarrollador. Solo los cambios rotundos de las sub-APIs estables tendrán un nuevo número de versión. Por ejemplo, de v1 a v2.

• Cambios secundarios: Las adiciones o correcciones retrocompatibles se presentan como cambios en la versión principal existente. Estos cambios se detallarán en las notas de la versión principal. Las incorporaciones que no interrumpen el funcionamiento de una sub-API se lanzarán en el canal alfa de la última versión estable o directamente en la última versión estable.

Política de descontinuación

Periódicamente, retiramos las versiones anteriores de las sub-APIs de Merchant. Nos comprometemos a ofrecer un período de baja de 12 meses para las versiones principales estables (vX), a partir del anuncio oficial de baja.

Por ejemplo, si damos de baja la versión 1 de la sub-API de Products el 15 de enero de 2026, esta dejará de estar disponible a partir del 15 de enero de 2027. Después de esta fecha, la versión anterior de la sub-API ya no estará disponible para su uso.

Versión de la API secundaria y estado del ciclo de vida

En la siguiente tabla, se enumeran las versiones más recientes de cada sub-API de la API de Merchant:

Prácticas recomendadas

• Consulta periódicamente las notas de la versión y las actualizaciones más recientes para conocer las versiones nuevas, las actualizaciones importantes, las mejoras y los anuncios sobre los lanzamientos y las bajas de sub-APIs.
• Si una sub-API tiene dos o más versiones estables, te sugerimos que uses la versión más reciente en todo momento.
• Diseña tu aplicación para que controle correctamente varios errores de la API secundaria, incluidos los problemas de red, los límites de frecuencia y los nuevos códigos o mensajes de error que se pueden introducir con versiones más recientes de la API secundaria.
• No esperes hasta que una versión secundaria de la API esté a punto de dejar de estar disponible para comenzar a planificar la actualización. Comienza a evaluar y probar las versiones nuevas en cuanto estén disponibles.
• Si tienes solicitudes de funciones o inquietudes sobre la hoja de ruta de una sub-API, comunícate con nosotros para hacernos preguntas o enviar comentarios. Para obtener información sobre cómo comunicarte con el equipo de la API de Merchant y recibir asistencia técnica, consulta Obtén ayuda con la API de Merchant.