Accesso alla Google Ads API nel 2026: i progetti Cloud sostituiscono i Developer Token

Dal 9 settembre 2026 l'accesso alla Google Ads API viene concesso per progetto Google Cloud anziché per Developer Token. Cosa è cambiato, come configurare l'accesso oggi e che cosa della guida di configurazione di giugno 2026 resta valido.

Cosa è cambiato il 9 settembre 2026

La nostra guida di giugno 2026 a configurazione, autenticazione e operazioni di lettura e scrittura della Google Ads API si basava sul Developer Token: lo si richiedeva in API Center di un account Manager, lì si faceva domanda per l'accesso Basic e il token veniva inviato a ogni chiamata. Tre mesi dopo, quel fondamento è cambiato. La documentazione di Google lo afferma ora senza ambiguità: «Developer tokens were sunset on September 9, 2026.»

La decisione sull'accesso non è scomparsa – si è spostata. Il livello di accesso all'API è ora determinato dal progetto Google Cloud usato per generare le credenziali OAuth, e gli accessi esistenti sono stati migrati automaticamente ai progetti Cloud. Le richieste non si presentano più in API Center: Google chiede agli sviluppatori di non richiedere più lì un Developer Token e di chiedere l'accesso dalla pagina Google Ads API Overview della Google Cloud Console. Le richieste Basic ancora in sospeso in API Center sono state chiuse e vanno ripresentate dalla Cloud Console.

La guida di giugno resta online così come è stata pubblicata, con una nota datata in testa. Questo approfondimento descrive ciò che è diverso oggi e rimanda alla guida dove il materiale precedente vale ancora.

I livelli di accesso ora appartengono al progetto Cloud

I livelli sono quelli noti, con una novità. I limiti seguenti derivano dalla documentazione di Google sui livelli di accesso, aggiornata a ottobre 2026:

Livello di accesso	Account di produzione	Operazioni giornaliere
Test	No, solo account di test	15.000
Explorer	Sì	2.880 sugli account di produzione
Basic	Sì	15.000
Standard	Sì	Nessun limite generale (singoli servizi possono comunque essere limitati)

Explorer è il punto di ingresso pratico. Secondo Google, una richiesta dalla Cloud Console viene esaminata automaticamente e, nella maggior parte dei casi, portata al livello Explorer – sufficiente per il reporting interno e per un'automazione contenuta sui propri account. Basic e Standard richiedono ancora una revisione ed entrambi hanno ora un nuovo prerequisito: la verifica del brand del progetto Google Cloud. Standard prevede inoltre un audit manuale.

Il problema è che la verifica del brand è facile da trascurare quando la configurazione tecnica funziona già. Uno script con accesso Explorer si comporta correttamente fino al raggiungimento del limite giornaliero: pianificate quindi la verifica prima che arrivino i volumi, non dopo.

Configurare l'accesso oggi

La sequenza è più breve di prima, perché il progetto Cloud è ora l'unico punto in cui si decide l'accesso:

Create un progetto Google Cloud, oppure scegliete quello che sarà titolare della vostra integrazione con Google Ads. La fatturazione non è necessaria.
Abilitate la Google Ads API nella libreria API del progetto.
Create le credenziali nello stesso progetto – un client OAuth per l'accesso basato sull'utente, oppure un account di servizio con chiave JSON.
Richiedete l'accesso dalla pagina Google Ads API Overview della Cloud Console e completate la verifica del brand se serve l'accesso Basic o Standard.

Il passaggio 3 è quello decisivo. Poiché l'accesso segue il progetto che ha emesso le credenziali OAuth, le credenziali di un secondo progetto non correlato non ereditano il livello di accesso richiesto. I team che nel tempo hanno creato client di test in progetti separati dovrebbero consolidarli prima di fare affidamento sull'accesso in produzione.

I dettagli OAuth della guida di giugno – lo scope adwords, l'accesso offline per ottenere un refresh token, i motivi per cui un refresh token smette di funzionare – restano invariati e validi.

Autenticazione e configurazione

Il Developer Token è ora di fatto facoltativo. Google indica che è possibile continuare a inviarlo negli header delle richieste, ma i server lo ignorano e si prevede che una futura versione major dell'API lo rifiuti. La versione 32.0.0 della libreria Python ufficiale ha rimosso il controllo che richiedeva un token nella configurazione.

Un google-ads.yaml minimo per OAuth basato sull'utente appare quindi così:

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: true

Per un account di servizio, json_key_file_path sostituisce le tre chiavi OAuth, eventualmente in combinazione con impersonated_email. Ogni chiave può essere impostata anche come variabile d'ambiente con il prefisso GOOGLE_ADS_, per esempio GOOGLE_ADS_JSON_KEY_FILE_PATH – la scelta più sensata sui server, dove i file di configurazione tendono a finire nei backup e nei repository.

login_customer_id mantiene il significato originario. Quando si raggiunge un account cliente tramite un account Manager, indica quell'account Manager (solo cifre, senza trattini). Senza di esso, tali chiamate falliscono con USER_PERMISSION_DENIED.

Versioni e libreria Python

Il pinning della versione merita più attenzione di quanta ne riceva di solito. La guida di giugno usava version="v22", e quella versione non è più disponibile: la release 33.0.0 della libreria Python google-ads ha rimosso v21 e v22. A ottobre 2026 la versione corrente dell'API è v26 (rilasciata il 14 ottobre 2026) e la libreria 34.0.0 ne aggiunge il supporto.

from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")

Fissare esplicitamente la versione resta l'impostazione predefinita corretta. In realtà, un client senza versione fissata cambia comportamento in silenzio al successivo aggiornamento della libreria, e Google ritira le versioni dell'API secondo un calendario pubblicato: una versione fissata trasforma almeno quel ritiro in una modifica pianificata anziché in una sorpresa.

La dichiarazione sulla pubblicità politica nell'UE

Un requisito ha colto di sorpresa molte integrazioni esistenti: il campo contains_eu_political_advertising della risorsa Campaign. Nelle versioni dell'API precedenti a v26, ogni nuova campagna deve dichiararlo. Dal 1° aprile 2026, le chiamate mutate falliscono con EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED quando un account contiene ancora campagne prive di dichiarazione. La versione 26 allenta la regola: il campo diventa facoltativo per le campagne che non si rivolgono in modo positivo all'UE.

Dichiararlo esplicitamente costa una riga e mantiene valido il codice di creazione delle campagne tra le versioni:

campaign.contains_eu_political_advertising = (
    client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)

Cosa resta valido della guida di giugno

Gran parte della guida precedente riguarda il lavoro con l'API più che l'accesso, e quella parte ha retto bene nel tempo. Le query di lettura GAQL, il pattern validate_only per testare in sicurezza le operazioni di scrittura, la gestione esplicita di update_mask e la separazione tra account Manager, progetto Cloud e account target valgono come descritto. Non vale più il percorso di accesso: API Center, la richiesta del Developer Token e il diagramma di architettura basato sul token.

Una buona integrazione – script interno o strumento per i clienti – tratta l'accesso come configurazione di proprietà di un progetto Cloud chiaramente identificato. Era una pratica sensata già prima di settembre 2026. Da allora è il modo in cui Google definisce l'accesso.