> For the complete documentation index, see [llms.txt](https://help.citrusad.com/retail-media-interface/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.citrusad.com/retail-media-interface/partner/es/deprecation-schedule-policy/api-deprecation-policy.md). # Directiva de obsolescencia de la API ## Por qué retiramos características Aquí en Epsilon Retail Media iteramos constantemente e introducimos nuevos productos y características. Por lo tanto, los cambios en nuestras API serán inevitables. Para ayudar a nuestros usuarios a planificar los cambios, seguimos una política de obsolescencia cuando hay una mejor versión disponible o cuando una característica está cerca del final de su soporte o lo ha alcanzado. El período de obsolescencia de una versión comienza en la fecha de anuncio de la obsolescencia. Las versiones marcadas para obsolescencia seguirán estando disponibles durante el período de obsolescencia de 3 meses. Una vez transcurrido el período de obsolescencia, se espera que la versión sea retirada, y Epsilon Retail Media ya no puede garantizar que estará disponible a partir de la fecha de desactivación definitiva. ## Reglas obligatorias de obsolescencia para nuestras API 1. Los cambios importantes, como la eliminación de elementos de la API, solo se introducen mediante el incremento de la versión de la API. * Una vez que se ha añadido un elemento de la API en una versión concreta, no se puede eliminar de esa versión ni cambiar significativamente su comportamiento 2. Los objetos de la API deben poder realizar un viaje de ida y vuelta (round-trip) entre versiones de la API en un lanzamiento determinado con una pérdida de información mínima o nula, con la excepción de recursos REST completos que no existan en algunas versiones. * Por ejemplo, un objeto se puede escribir como v1 y luego leerse de nuevo como v2 y convertirse a v1, y el recurso v1 resultante será idéntico al original. La representación en v2 puede ser diferente de la v1, pero el sistema sabe cómo convertir entre ellas en ambas direcciones. Además, cualquier campo nuevo añadido en v2 debe poder realizar el viaje de ida y vuelta a v1 y regresar, lo que significa que v1 podría tener que añadir un campo equivalente, mapearse a un campo equivalente o representarlo como una anotación. * Con cambios significativos en las características del producto, haremos todo lo posible para diseñar nuestras API de modo que sean compatibles con versiones anteriores, pero puede haber circunstancias excepcionales en las que esto no sea posible. Discutiremos estas excepciones con nuestros socios. 3. Una versión de la API no se puede marcar como obsoleta en favor de una versión de la API menos estable. * Una versión de la API de disponibilidad general (GA) puede reemplazar a las versiones Alfa y Beta menos estables * Las versiones Beta pueden reemplazar a versiones Beta o Alfa anteriores, pero no se pueden utilizar para reemplazar una versión de la API GA * Las versiones Alfa pueden reemplazar a versiones Alfa anteriores, pero no se pueden utilizar para reemplazar una versión Beta o la versión GA 4. Las versiones de la API marcadas para obsolescencia recibirán soporte durante un máximo de 3 meses a partir de la fecha del aviso. Anunciaremos cuándo finalizarán el soporte y la disponibilidad de la versión. Las versiones Alfa y Beta pueden quedar obsoletas antes a medida que se introduzca una versión de la API GA preferida. * Las nuevas versiones de la API solo se introducirán como parte de un lanzamiento que admita tanto la versión nueva como la versión anterior * Esto da tiempo para que los usuarios migren a la última versión o reviertan los cambios cuando sea necesario dentro del período de tiempo en el que la versión anterior ya no esté disponible y haya sido retirada 5. Realizar llamadas a una versión retirada puede dar lugar a un comportamiento impredecible o a una respuesta no válida. ## Excepciones Una política no puede cubrir todas las situaciones posibles. Este es un documento vivo y siempre evolucionará con el tiempo. Cuando haya situaciones que no encajen perfectamente en esta política, o para las cuales esta política se convierta en un impedimento grave, analice el desafío con el equipo de para encontrar las mejores soluciones para esos casos específicos. Epsilon Retail Media se compromete a ofrecer una integración estable que, en la medida de lo posible, no interrumpa a nuestros usuarios. Las excepciones siempre se anunciarán en todas las notas de lanzamiento relevantes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.citrusad.com/retail-media-interface/partner/es/deprecation-schedule-policy/api-deprecation-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.