El versionado de API no es un detalle que solo mire el equipo de desarrollo: cada vez que Google, Meta o tu CRM publican una versión nueva, la anterior tiene fecha de caducidad. Pasado ese plazo, las llamadas que alimentan tus informes de Google Ads, tus audiencias de Meta o la sincronización con el CRM pueden fallar de golpe o, peor, seguir funcionando con datos calculados de otra forma. Esto va dirigido a quien gestiona esas integraciones o responde cuando dejan de cuadrar los números: qué plazos maneja cada proveedor y qué hacer antes de que llegue la fecha.
El versionado de API marca una fecha de caducidad por versión: Google Ads retira cada versión principal unos doce meses después de publicarla, Meta da dos años de vida al Graph API y mucho menos a su Marketing API, y pasado ese plazo las llamadas fallan o cambian de versión sin avisar. Revisar el calendario de cada proveedor antes de esa fecha es lo que evita el corte.
Qué es el versionado de API
Versionar una API es publicar los cambios bajo un número o una fecha concreta, en lugar de modificar el comportamiento sobre la marcha. Cada integración -Google Ads, el Graph API de Meta, el CRM, la pasarela de pago- declara con qué versión habla, y el proveedor se compromete a mantenerla estable durante un plazo. Pasado ese plazo, deja de dar soporte a esa versión: la retira, la redirige a otra automáticamente o directamente devuelve un error.
El problema no es el cambio en sí, sino que casi nunca lo nota quien gestiona el marketing. El aviso llega al correo técnico de turno, a veces meses antes, y si nadie lo traduce en una tarea con fecha, el día de la caducidad el informe de campañas se queda en blanco o, lo que es peor, sigue trayendo datos pero calculados con reglas distintas a las de la semana anterior. Quien construye la integración sobre un desarrollo de software a medida puede fijar esa versión desde el primer día en vez de heredar la que venía por defecto.
Google Ads jubila una versión de API cada año
Desde enero de 2026, Google Ads API publica una versión nueva cada mes y da a las versiones principales una vida de unos doce meses desde su lanzamiento. La v19 dejó de responder el 11 de febrero de 2026, la v20 lo hizo el 10 de junio y la v21 lo hace el 5 de agosto; la v22 tiene previsto su cierre en octubre. Quien automatiza informes o pujas con esta API hereda ese calendario aunque no lo pida, y conviene no confundirlo con el límite de peticiones de la API, que es un problema de cuota diaria, no de versión caducada.
Las llamadas a una versión caducada fallan sin aviso
Aquí no hay término medio: pasada la fecha de cierre, cada petición a esa versión devuelve un error y la integración se detiene, no se degrada poco a poco. Si la cuenta de un cliente reporta pujas o conversiones a través de un script o un plugin de hace dos años, es frecuente que nadie haya tocado la versión declarada en el código, así que el fallo aparece de golpe el día del cierre, con el informe en blanco. El propio blog de desarrolladores de Google Ads avisa con varios meses de margen, pero ese aviso llega a quien programó la integración, no a quien revisa el gasto en campañas: sin un canal entre los dos equipos, la fecha pasa en silencio hasta que falla.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Meta diferencia entre Graph API y Marketing API
El Graph API de Meta da dos años de vida a cada versión, contados desde que sale la siguiente: la v20 se retiró el 24 de septiembre de 2026 y la v21 lo hará el 21 de enero de 2027. La Marketing API, la que mueve campañas y audiencias de Facebook e Instagram, recorta ese plazo a apenas unos meses tras cada lanzamiento, mucho antes de que caduque el Graph API general.
La llamada no falla, pero cambia de versión sola
En el Graph API general, una llamada a una versión retirada no devuelve un error: Meta la redirige en silencio a la versión más antigua que siga activa, según explica su propia guía oficial de versionado. Parece más cómodo que un fallo, pero significa que el comportamiento de la integración cambia solo, sin que nadie lo haya pedido ni lo note en el código de un día para otro. En la Marketing API el criterio es el opuesto: pasada su ventana, mucho más corta, la llamada falla directamente. Para quien reporta resultados de campañas en Meta, esa diferencia importa: un informe que sigue funcionando no es garantía de que esté usando las mismas reglas que la semana pasada.
El modelo de Stripe evita el versionado forzoso
Stripe resuelve el mismo problema al revés: cada cuenta queda fijada a la versión activa el día que se crea, y esa fecha no se mueve a menos que alguien la cambie a mano desde el panel. Según explica la propia compañía en su blog técnico de versionado, publica versiones mensuales sin cambios que rompan nada y, un par de veces al año, una versión mayor con cambios de fondo que cada cliente decide cuándo adoptar.
Qué puedes copiar de Stripe sin ser Stripe
Pocas empresas tienen el equipo para mantener décadas de versiones en paralelo, pero la idea de fondo sí se puede aplicar a cualquier integración propia: fijar la versión de forma explícita en el código, nunca dejar que la petición use la última por defecto, y anotar en un calendario la fecha de cierre de cada proveedor con el que se trabaja. Esa es justo la tarea que suele recaer en quien lleva el mantenimiento de servidores o la infraestructura técnica, revisando ese calendario una vez al trimestre en vez de enterarse el día que el informe deja de llegar.
Cómo blindar tu integración de API en marketing
Antes de que llegue la fecha de cierre de cualquier proveedor, conviene dejar resuelto lo siguiente:
- Fijar la versión de cada API de forma explícita en el código o la configuración, nunca a la deriva.
- Anotar en un calendario compartido entre marketing y desarrollo la fecha de retirada de cada proveedor que se usa.
- Probar la versión siguiente en un entorno de pruebas antes de que caduque la actual, no el mismo día del cierre.
- Asignar una persona responsable de leer los avisos técnicos de Google, Meta y el resto de proveedores conectados.
Quien delega el mantenimiento en una consultoría de sistemas suele llevar ese calendario como parte del contrato; quien lo gestiona dentro de casa necesita que alguien lo haga suyo, porque ningún proveedor avisa dos veces.
Preguntas frecuentes sobre el versionado de API
¿Qué es el versionado de API?
Es el sistema con el que un proveedor publica cambios bajo una versión o fecha concreta, en vez de modificar la API sin aviso. Cada versión tiene una fecha de caducidad: pasado ese plazo, el proveedor deja de darle soporte y las llamadas fallan o cambian de comportamiento.
¿Cada cuánto cambia de versión la API de Google Ads?
Desde 2026 publica una versión cada mes, y cada versión principal deja de funcionar unos doce meses después de su lanzamiento. La v21, por ejemplo, se retira el 5 de agosto de 2026, y la siguiente sigue el mismo calendario poco después.
¿Qué pasa si no migro antes de la fecha de cierre?
Depende del proveedor: en la API de Google Ads o en la Marketing API de Meta, las llamadas fallan directamente. En el Graph API general de Meta, en cambio, se redirigen solas a la versión más antigua que siga activa, sin avisar.
¿Hay alguna API que no obligue a migrar nunca?
Stripe fija cada cuenta a la versión activa el día que se crea y no la cambia salvo que alguien lo haga a mano. No es la norma: la mayoría de proveedores de marketing y publicidad sí retiran versiones con fecha fija.
Fuente: Google Ads API Developer Blog
