Acceso a la API de Google Ads en 2026: los proyectos de Cloud sustituyen a los Developer Tokens
Desde el 9 de septiembre de 2026, el acceso a la API de Google Ads se concede por proyecto de Google Cloud en lugar de por Developer Token. Qué ha cambiado, cómo configurar el acceso hoy y qué sigue siendo válido de la guía de configuración de junio de 2026.
Qué cambió el 9 de septiembre de 2026
Nuestra guía de junio de 2026 sobre configuración, autenticación y operaciones de lectura y escritura de la API de Google Ads se basaba en el Developer Token: se solicitaba en API Center de una cuenta de Gestor, allí se pedía el acceso Basic y el token se enviaba en cada llamada. Tres meses después, ese cimiento ha cambiado. La documentación de Google lo expone ahora sin ambigüedad: «Developer tokens were sunset on September 9, 2026.»
La decisión de acceso no ha desaparecido – se ha desplazado. El nivel de acceso a la API se determina ahora por el proyecto de Google Cloud con el que generó sus credenciales OAuth, y los accesos existentes se migraron automáticamente a proyectos de Cloud. Las solicitudes ya no se realizan en API Center: Google pide a los desarrolladores que no soliciten allí un Developer Token y que pidan el acceso desde la página Google Ads API Overview de la Google Cloud Console. Las solicitudes Basic que seguían pendientes en API Center se cerraron y deben presentarse de nuevo desde la Cloud Console.
La guía de junio sigue en línea tal como se publicó, con una nota fechada al principio. Esta continuación describe lo que es distinto hoy y remite a la guía donde el material anterior sigue siendo aplicable.
Los niveles de acceso pertenecen ahora al proyecto de Cloud
Los niveles son los ya conocidos, con una incorporación. Los límites siguientes proceden de la documentación de Google sobre niveles de acceso, a octubre de 2026:
| Nivel de acceso | Cuentas de producción | Operaciones diarias |
|---|---|---|
| Test | No, solo cuentas de prueba | 15.000 |
| Explorer | Sí | 2.880 en cuentas de producción |
| Basic | Sí | 15.000 |
| Standard | Sí | Sin límite general (algunos servicios pueden seguir estando limitados) |
Explorer es el punto de entrada práctico. Según Google, una solicitud desde la Cloud Console se revisa automáticamente y, en la mayoría de los casos, se eleva a acceso Explorer – suficiente para informes internos y una automatización moderada sobre sus propias cuentas. Basic y Standard siguen exigiendo una revisión, y ambos tienen ahora un nuevo requisito previo: la verificación de marca del proyecto de Google Cloud. Standard implica además una auditoría manual.
El problema es que la verificación de marca se pasa por alto con facilidad cuando la configuración técnica ya funciona. Un script con acceso Explorer se comportará correctamente hasta alcanzar el límite diario, así que planifique la verificación antes de que llegue el volumen, no después.
Configurar el acceso hoy
La secuencia es más corta que antes, porque el proyecto de Cloud es ahora el único lugar donde se decide el acceso:
- Cree un proyecto de Google Cloud o elija el que será titular de su integración con Google Ads. No se necesita facturación para ello.
- Habilite la API de Google Ads en la biblioteca de APIs del proyecto.
- Cree las credenciales en ese mismo proyecto – un cliente OAuth para acceso basado en usuario o una cuenta de servicio con clave JSON.
- Solicite el acceso en la página Google Ads API Overview de la Cloud Console y complete la verificación de marca si necesita acceso Basic o Standard.
Lo decisivo es el paso 3. Como el acceso sigue al proyecto que emitió las credenciales OAuth, las credenciales de un segundo proyecto sin relación no heredan el nivel de acceso solicitado. Los equipos que han creado clientes de prueba en proyectos separados a lo largo de los años deberían consolidarlos antes de depender del acceso en producción.
Los detalles de OAuth de la guía de junio – el scope adwords, el acceso sin conexión para obtener un refresh token, los motivos por los que un refresh token deja de funcionar – no cambian y siguen siendo válidos.
Autenticación y configuración
El Developer Token es ahora opcional en la práctica. Google indica que puede seguir enviándolo en las cabeceras de las solicitudes, pero los servidores lo ignoran, y se espera que una futura versión mayor de la API lo rechace. La versión 32.0.0 de la biblioteca oficial de Python eliminó la comprobación que exigía un token en la configuración.
Un google-ads.yaml mínimo para OAuth basado en usuario queda, por tanto, así:
client_id: YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret: YOUR_CLIENT_SECRET
refresh_token: YOUR_REFRESH_TOKEN
login_customer_id: "1234567890"
use_proto_plus: truePara una cuenta de servicio, json_key_file_path sustituye a las tres claves de OAuth, opcionalmente combinada con impersonated_email. Cada clave también puede definirse como variable de entorno con el prefijo GOOGLE_ADS_, por ejemplo GOOGLE_ADS_JSON_KEY_FILE_PATH – la opción más sensata en servidores, donde los archivos de configuración suelen acabar en copias de seguridad y repositorios.
login_customer_id conserva su significado anterior. Cuando se accede a una cuenta de cliente a través de una cuenta de Gestor, indica esa cuenta de Gestor (solo dígitos, sin guiones). Sin él, esas llamadas fallan con USER_PERMISSION_DENIED.
Versiones y la biblioteca de Python
La fijación de versión merece más atención de la que suele recibir. La guía de junio usaba version="v22", y esa versión ya no está disponible: la versión 33.0.0 de la biblioteca de Python google-ads eliminó v21 y v22. A octubre de 2026, la versión actual de la API es v26 (publicada el 14 de octubre de 2026), y la biblioteca 34.0.0 añade su compatibilidad.
from google.ads.googleads.client import GoogleAdsClient
client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")Fijar la versión de forma explícita sigue siendo la opción predeterminada correcta. En la práctica, un cliente sin versión fijada cambia de comportamiento sin avisar en la siguiente actualización de la biblioteca, y Google retira las versiones de la API según un calendario publicado: una versión fijada convierte al menos esa retirada en un cambio planificado en lugar de una sorpresa.
La declaración de publicidad política de la UE
Un requisito ha afectado a muchas integraciones existentes: el campo contains_eu_political_advertising del recurso Campaign. En las versiones de la API anteriores a v26, toda campaña nueva debe declararlo. Desde el 1 de abril de 2026, las llamadas mutate fallan con EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED cuando una cuenta aún contiene campañas sin declarar. La versión 26 lo flexibiliza: el campo pasa a ser opcional para las campañas que no se dirigen de forma positiva a la UE.
Declararlo explícitamente cuesta una línea y mantiene válido el código de creación de campañas en todas las versiones:
campaign.contains_eu_political_advertising = (
client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)Qué se mantiene de la guía de junio
Gran parte de la guía anterior trata de trabajar con la API más que de acceder a ella, y esa parte ha envejecido bien. Las consultas de lectura GAQL, el patrón validate_only para probar con seguridad las operaciones de escritura, la gestión explícita de update_mask y la separación entre cuenta de Gestor, proyecto de Cloud y cuenta de destino se aplican tal como se describen. Lo que ya no se aplica es la vía de acceso: API Center, la solicitud del Developer Token y el diagrama de arquitectura basado en el token.
Una buena integración – script interno o herramienta para clientes – trata el acceso como una configuración que pertenece a un proyecto de Cloud claramente identificado. Era una práctica sensata antes de septiembre de 2026. Desde entonces, es la forma en que Google define el acceso en primer lugar.