Google Ads API-Zugriff 2026: Cloud-Projekte ersetzen Developer Tokens

Seit dem 9. September 2026 wird der Google Ads API-Zugriff pro Google Cloud-Projekt statt pro Developer Token vergeben. Was sich geändert hat, wie Sie den Zugriff heute einrichten und was der Einrichtungsleitfaden vom Juni 2026 weiterhin zutreffend beschreibt.

Was sich am 9. September 2026 geändert hat

Unser Leitfaden vom Juni 2026 zu Google Ads API-Einrichtung, Authentifizierung sowie Lese- und Schreiboperationen baute auf dem Developer Token auf: Er wird im API Center eines Manager-Kontos angefordert, dort wird der Basic-Zugriff beantragt, und der Token wird bei jedem Aufruf mitgesendet. Drei Monate später hat sich diese Grundlage verschoben. Die Dokumentation von Google hält es mittlerweile unmissverständlich fest: „Developer tokens were sunset on September 9, 2026.“

Die Entscheidung über den Zugriff selbst ist nicht entfallen – sie hat sich verlagert. Ihre API-Zugriffsstufe richtet sich nun nach dem Google Cloud-Projekt, mit dem Sie Ihre OAuth-Zugangsdaten erzeugt haben, und bestehende Zugriffe wurden automatisch auf Cloud-Projekte migriert. Anträge werden nicht mehr im API Center gestellt; Google bittet Entwickler, dort keinen Developer Token mehr zu beantragen und den Zugriff stattdessen auf der Seite „Google Ads API Overview“ in der Google Cloud Console anzufordern. Basic-Anträge, die im API Center noch offen waren, wurden geschlossen und müssen erneut über die Cloud Console eingereicht werden.

Der Leitfaden vom Juni bleibt unverändert online, ergänzt um einen datierten Hinweis am Anfang. Dieser Folgebeitrag beschreibt, was heute anders ist, und verweist dorthin zurück, wo das frühere Material weiterhin gilt.

Zugriffsstufen gehören jetzt zum Cloud-Projekt

Die Stufen selbst sind bekannt, mit einer Ergänzung. Die folgenden Limits stammen aus der Dokumentation von Google zu den Zugriffsstufen, Stand Oktober 2026:

Zugriffsstufe	Produktivkonten	Tägliche Operationen
Test	Nein, nur Testkonten	15.000
Explorer	Ja	2.880 gegenüber Produktivkonten
Basic	Ja	15.000
Standard	Ja	Keine allgemeine Obergrenze (einzelne Dienste können weiterhin begrenzt sein)

Explorer ist der praktische Einstieg. Laut Google wird ein Antrag aus der Cloud Console automatisch geprüft und in den meisten Fällen auf Explorer-Zugriff hochgestuft – ausreichend für internes Reporting und moderate Automatisierung auf Ihren eigenen Konten. Basic und Standard erfordern weiterhin eine Prüfung, und beide setzen nun zusätzlich die Markenverifizierung des Google Cloud-Projekts voraus. Standard umfasst darüber hinaus ein manuelles Audit.

Das Problem: Die Markenverifizierung wird leicht übersehen, solange die technische Einrichtung bereits funktioniert. Ein Skript mit Explorer-Zugriff verhält sich korrekt, bis es das Tageslimit erreicht – planen Sie die Verifizierung daher ein, bevor das Volumen entsteht, nicht danach.

Zugriff heute einrichten

Die Abfolge ist kürzer als zuvor, weil das Cloud-Projekt nun die einzige Stelle ist, an der über den Zugriff entschieden wird:

Erstellen Sie ein Google Cloud-Projekt oder wählen Sie dasjenige aus, das Ihre Google Ads-Integration besitzen soll. Eine Abrechnung ist dafür nicht erforderlich.
Aktivieren Sie die Google Ads API in der API-Bibliothek des Projekts.
Erstellen Sie die Zugangsdaten im selben Projekt – einen OAuth-Client für nutzerbasierten Zugriff oder ein Dienstkonto mit JSON-Schlüssel.
Beantragen Sie den Zugriff auf der Seite „Google Ads API Overview“ in der Cloud Console und schließen Sie die Markenverifizierung ab, falls Sie Basic- oder Standard-Zugriff benötigen.

Entscheidend ist Schritt 3. Da der Zugriff dem Projekt folgt, das die OAuth-Zugangsdaten ausgestellt hat, erben Zugangsdaten aus einem zweiten, davon unabhängigen Projekt die beantragte Zugriffsstufe nicht. Teams, die über die Jahre Testclients in separaten Projekten angelegt haben, sollten diese konsolidieren, bevor sie sich auf Produktivzugriff verlassen.

Die OAuth-Details aus dem Leitfaden vom Juni – der Scope adwords, Offline-Zugriff für ein Refresh Token, die Gründe, warum ein Refresh Token nicht mehr funktioniert – sind unverändert und gelten weiterhin.

Authentifizierung und Konfiguration

Der Developer Token ist in der Praxis nun optional. Laut Google können Sie ihn weiterhin in den Request-Headern senden, die Server ignorieren ihn jedoch, und eine künftige Hauptversion der API soll ihn voraussichtlich ablehnen. Version 32.0.0 der offiziellen Python-Bibliothek hat die Prüfung entfernt, die einen Token in der Konfiguration verlangte.

Eine minimale google-ads.yaml für nutzerbasiertes OAuth sieht daher so aus:

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

Bei einem Dienstkonto ersetzt json_key_file_path die drei OAuth-Schlüssel, optional kombiniert mit impersonated_email. Jeder Schlüssel lässt sich auch als Umgebungsvariable mit dem Präfix GOOGLE_ADS_ setzen, zum Beispiel GOOGLE_ADS_JSON_KEY_FILE_PATH – die sinnvollere Wahl auf Servern, wo Konfigurationsdateien erfahrungsgemäß in Backups und Repositories landen.

login_customer_id behält seine bisherige Bedeutung. Wenn Sie ein Kundenkonto über ein Manager-Konto erreichen, bezeichnet der Wert dieses Manager-Konto (nur Ziffern, keine Bindestriche). Ohne ihn schlagen solche Aufrufe mit USER_PERMISSION_DENIED fehl.

Versionen und die Python-Bibliothek

Die Versionsfixierung verdient mehr Aufmerksamkeit, als sie üblicherweise erhält. Der Leitfaden vom Juni verwendete version="v22", und diese Version ist nicht mehr verfügbar: Release 33.0.0 der Python-Bibliothek google-ads hat v21 und v22 entfernt. Stand Oktober 2026 ist v26 die aktuelle API-Version (veröffentlicht am 14. Oktober 2026), und die Bibliothek 34.0.0 unterstützt sie.

from google.ads.googleads.client import GoogleAdsClient

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

Die explizite Fixierung der Version bleibt der richtige Standard. In der Praxis ändert ein Client ohne fixierte Version sein Verhalten beim nächsten Bibliotheks-Upgrade unbemerkt, und Google stellt API-Versionen nach einem veröffentlichten Zeitplan ein – eine fixierte Version macht diese Einstellung zumindest zu einer geplanten Änderung statt zu einer Überraschung.

Die EU-Erklärung zu politischer Werbung

Eine Anforderung hat viele bestehende Integrationen getroffen: das Feld contains_eu_political_advertising der Ressource Campaign. In API-Versionen vor v26 muss jede neue Kampagne es angeben. Seit dem 1. April 2026 schlagen Mutate-Aufrufe mit EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED fehl, wenn ein Konto noch Kampagnen ohne Erklärung enthält. Version 26 lockert dies: Das Feld wird für Kampagnen optional, die die EU nicht gezielt ansprechen.

Die explizite Angabe kostet eine Zeile und hält Code zur Kampagnenerstellung über alle Versionen hinweg gültig:

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

Was aus dem Leitfaden vom Juni weiterhin gilt

Der Großteil der früheren Anleitung betrifft die Arbeit mit der API und nicht den Zugang zu ihr – und dieser Teil ist gut gealtert. GAQL-Leseabfragen, das Muster validate_only zum sicheren Testen von Schreiboperationen, der explizite Umgang mit update_mask und die Trennung von Manager-Konto, Cloud-Projekt und Zielkonto gelten unverändert. Nicht mehr zutreffend ist der Zugangsweg: das API Center, der Antrag auf einen Developer Token und das tokenbasierte Architekturdiagramm.

Eine gute Integration – ob internes Skript oder Kundenwerkzeug – behandelt den Zugriff als Konfiguration, die einem klar benannten Cloud-Projekt gehört. Das war schon vor September 2026 eine sinnvolle Praxis. Seitdem ist es die Art, wie Google den Zugriff überhaupt definiert.