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 en el nivel de la sub-API. Esto significa que los componentes o servicios individuales dentro de la API de Merchant tendrán su propio ciclo de vida de versión.
Formato y presentación del control de versiones
Versiones estables de sub-API: Si una sub-API está en versión estable, todos sus métodos también lo están. La versión estable de la sub-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. La versión de la sub-API alfa se representa como vXalpha (por ejemplo, v1alpha o v2alpha). Estas son versiones experimentales de acceso anticipado destinadas a pruebas y iteraciones rápidas. Las versiones alfa no tienen garantía de estabilidad ni ciclo de vida garantizado. Las versiones alfa 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 v1 a la v2): Estos indicadores son cambios incompatibles con versiones anteriores y rotundos, que requieren la acción del desarrollador. Solo los cambios rotundos de las sub-APIs estables tendrán un número de versión nuevo. Por ejemplo, de v1 a v2.
Cambios menores: Las correcciones o incorporaciones retrocompatibles se presentan como cambios en la versión principal existente. Estos cambios se detallarán en las notas de la versión de esa versión principal. Las incorporaciones sin interrupciones a una sub-API se lanzarán en el canal alfa de la versión estable más reciente o directamente en la versión estable más reciente.
Puestas de sol
Periódicamente, damos de baja las versiones anteriores de las subAPI de Merchant. Nos comprometemos a brindar 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 v1 de la sub-API de Products el 15 de enero de 2026, esta dejará de estar disponible antes del 15 de enero de 2027. Después de esa fecha, la versión anterior de la sub-API ya no estará disponible para su uso.
Estado del ciclo de vida y versión de la subAPI
En la siguiente tabla, se enumeran las versiones más recientes de cada sub-API de la API de Merchant:
Sub-API | Versiones alfa | Versiones beta | Estado |
---|---|---|---|
Cuentas | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Productos | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Entradas de productos | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Inventarios locales | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Inventarios regionales | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Fuentes de datos | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Promociones | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Informes | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Conversiones | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Notificaciones | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Opiniones | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Configuración de envío | No disponible | Versión beta de v1 | La versión beta v1 está activa |
Product Studio | v1 alfa | No disponible | La versión alfa v1 está activa |
Prácticas recomendadas
- Revisa periódicamente las notas de la versión y las actualizaciones más recientes para conocer las versiones nuevas, las actualizaciones principales, las mejoras y los anuncios sobre lanzamientos y baja de sub-APIs.
- Si una sub-API tiene 2 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 de forma fluida varios errores de sub-API, incluidos los problemas de red, los límites de frecuencia y los nuevos códigos de error o mensajes que podrían presentarse con versiones más recientes de sub-API.
- No esperes hasta que una versión secundaria de la API esté a punto de dejar de estar disponible para comenzar a planificar tu actualización. Comienza a evaluar y probar las versiones nuevas en cuanto estén disponibles.
- Si tienes solicitudes de funciones o inquietudes sobre un cronograma de sub-API, comunícate con nosotros para enviarnos preguntas o comentarios. Para obtener información sobre cómo comunicarte con el equipo de la API de Merchant para obtener asistencia técnica, consulta Obtén ayuda con la API de Merchant.