English
Deutsch
PolskiGoogle Ads API: Cloud-Projekt-Zugriff und der v22-Stichtag am 7. Oktober 2026
Management Summary
Die Google Ads API verbindet externe Programme mit Werbekonten, etwa für Berichte und automatische Kampagnenänderungen. Zwei getrennte Änderungen betreffen diese Verbindung: Freigaben werden nun über Google-Cloud-Projekte verwaltet, die Anwendungseinstellungen bündeln; Version 22 wurde am 7. Oktober 2026 abgeschaltet. Unternehmen und Agenturen brauchen sowohl gültigen Zugriff als auch eine unterstützte Version. Die Trennung hilft, Fehler auch in selten laufenden Aufgaben zu erkennen.
Inhalt
- Entscheidend ist das Projekt hinter den Zugangsdaten
- Drei Ebenen auseinanderhalten
- Was bei einer fehlgeschlagenen Anfrage ins Protokoll gehört
- Der v22-Termin gilt unabhängig davon
- Eine kontrollierte Änderung statt mehrerer gleichzeitiger Reparaturen
- Zuständigkeit gehört zur Betriebsfähigkeit
- Passendes Werkzeug
- Fragen und Antworten
- Quellen
Seit dem 9. September 2026 wird der Zugriff auf die Google Ads API über Google-Cloud-Projekte verwaltet. Der davon unabhängige Abschalttermin für v22 war der 7. Oktober 2026 und liegt inzwischen zurück. Eine Projektfreigabe stellt eine abgeschaltete API-Version nicht wieder her; eine neuere Bibliothek erteilt einem Projekt keinen Produktionszugriff. [1, 2, 3]
Entscheidend ist das Projekt hinter den Zugangsdaten
Im neuen Google-Modell gehört die Zugriffsstufe zum Cloud-Projekt, über das die Authentifizierung erfolgt. Bei einer Nutzeranmeldung ist das das Projekt des OAuth-Clients, bei einem Dienstkonto dessen Projekt. Bestehende Zugriffsstufen wurden anhand der API-Nutzung in den 90 Tagen vor der Umstellung übertragen. Ein seit Jahren genehmigter Entwicklertoken beweist deshalb nicht, dass jedes Projekt einer Organisation die erwartete Freigabe besitzt. [1, 2]
Ein Cloud-Projekt bündelt Anwendungseinstellungen und API-Zugriff in Google Cloud. Ein OAuth-Client kennzeichnet eine Anwendung, die über eine Nutzeranmeldung Zugriff anfordert. Ein Dienstkonto besitzt eine eigene Identität für automatische Prozesse. Die Projektfreigabe und die Berechtigung zum Lesen oder Ändern eines bestimmten Ads-Kontos sind getrennte Freigaben.
Eine fiktive Agentur betreibt einen täglichen Berichtsdienst und eine zweite Anwendung für gelegentliche Migrationen. Beide verwendeten bisher denselben genehmigten Entwicklertoken, ihre Zugangsdaten gehören aber zu unterschiedlichen Projekten. Der funktionierende Berichtsdienst sagt wenig über die aktuelle Einsatzbereitschaft der zweiten Anwendung aus. Die Bestandsaufnahme benötigt das Projekt der Zugangsdaten, nicht nur die Kennung des Verwaltungskontos.
Drei Ebenen auseinanderhalten
| Ebene | Prüffrage |
|---|---|
| Authentifizierung | Welcher Nutzer oder welches Dienstkonto stellt die Anfrage? |
| API-Zugriff | Welche Zugriffsstufe hat das zugehörige Cloud-Projekt? |
| API-Version | Verwendet die Anfrage eine unterstützte Version? |
Die Berechtigungen am Kundenkonto bleiben eine weitere Voraussetzung. Die Tabelle beschreibt eine Untersuchungsreihenfolge und keine Garantie für jede mögliche Operation. Diese Reihenfolge soll verhindern, dass ein Versionsproblem als Passwortproblem behandelt wird oder eine fehlende Projektfreigabe einen unnötigen Kampagnenumbau auslöst.
Was bei einer fehlgeschlagenen Anfrage ins Protokoll gehört
Google dokumentiert für v25 und neuer den Fehler CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION, wenn ein Projekt mit Testzugriff ein Produktionskonto anspricht. Ältere Versionen verwenden dafür ACTION_NOT_PERMITTED. Die aktuelle Hilfeseite nennt außerdem Übergangsprobleme bei einigen neu freigegebenen Projekten. Eine sichtbare Freigabe und eine abgewiesene Anfrage erfordern deshalb eine Untersuchung; daraus folgen nicht automatisch falsche Zugangsdaten. [2]
Integrationsverzeichnis – Beispielfelder
Anwendung und zuständiges Team
Cloud-Projektnummer
Anmeldeverfahren und Kennung der Zugangsdaten
Zielkonto: Test oder Produktion
In Anfragen beobachtete API-Version
Exakter Fehlercode und Anfragekennung
Zeitpunkt des letzten erfolgreichen LaufsIn dieses Verzeichnis gehören Kennungen, keine geheimen Werte. Refresh-Token, private Schlüssel und Client-Secrets sind kein Inhalt einer Störungstabelle. Bei der fiktiven Agentur trennt ein solches Protokoll den vergessenen Monatsprozess vom funktionierenden täglichen Bericht, ohne dafür Kampagneneinstellungen zu verändern.
Der v22-Termin gilt unabhängig davon
Laut Googles Abschaltankündigung schlagen v22-Anfragen ab dem 7. Oktober 2026 fehl. Die API-Messwerte in der Cloud Console helfen dabei, kürzlich aufgerufene Methoden zu finden; deren Name enthält die Version. Das ergänzt eine Quellcodesuche, weil ein alter bereitgestellter Prozess weiterlaufen kann, obwohl das Hauptrepository bereits aktualisiert wurde. [3]
Zur Prüfung gehören geplante Exporte, Conversion-Uploads, Wartungsskripte und selten verwendete Verwaltungsaufgaben. Ein erfolgreich aktualisiertes Dashboard reicht nicht aus, wenn der nächtliche Import weiterhin v22 nutzt. Maßgeblich sind die tatsächlich ausgeführten Operationen. Lesende Abfragen und schreibende Vorgänge benötigen dabei getrennte Proben.
Eine kontrollierte Änderung statt mehrerer gleichzeitiger Reparaturen
Ein praktikabler Ablauf dokumentiert zunächst die Projektfreigabe, aktualisiert danach Bibliothek und betroffenen Anfragecode und prüft anschließend repräsentative Vorgänge. Soweit möglich, bietet ein getrenntes Testkonto Raum für Proben vor produktiven Schreibzugriffen. Das Protokoll sollte zwischen Validierung und tatsächlich ausgeführter Änderung unterscheiden und erzeugte Ressourcenkennungen aufbewahren.
Der bisherige Developer-Token-Header ist laut Google derzeit optional und wird ignoriert. Google empfiehlt seine Entfernung und kündigt die Ablehnung für eine künftige Hauptversion an. Ohne weitere Ankündigung darf dieser spätere Schritt nicht auf den v22-Abschalttermin gelegt werden. Aktualisierte Bibliotheken unterstützen Anfragen ohne diesen Token. [1, 2]
Zuständigkeit gehört zur Betriebsfähigkeit
Auch die Kontakte mit Owner- und Editor-Rollen im Projekt werden für Dienstankündigungen relevant. Eine technisch funktionierende Integration kann schlecht betreut sein, wenn Hinweise ehemalige Mitarbeiter erreichen. Zuständigkeit und Alarmwege gehören deshalb neben die technische Migration. Der verknüpfte Passkey-Beitrag behandelt eine andere Ebene: das menschliche Konto hinter einer Freigabe. Diese Frage ist von der hier beschriebenen Projektfreigabe zu trennen.
Passendes Werkzeug
GoogleAds – GAQL-Abfrage-Explorer
Passkey-Pflicht für die Google Ads API: Geltungsbereich und vergessene Autorisierungen
Fragen und Antworten
Wie lassen sich selten laufende Prozesse finden, die noch v22 verwenden?
Über mehrere Quellen, weil jede nur einen Teil sieht:
- Die API-Messwerte in der Cloud Console, und zwar je Projekt. Die Messwerte zeigen nur Aufrufe aus dem gewählten Projekt und nur aus dem gewählten Zeitraum; ein Quartalsexport, der in diesem Zeitraum nicht lief, erscheint dort nicht, und ein zweites Projekt erscheint erst, wenn es ausgewählt ist.
- Zu prüfen sind die bereitgestellten Abhängigkeiten und die Anfragekonfiguration. Ein Lockfile legt Bibliotheksversionen fest; ein Container-Image enthält eine bestimmte Installation. Beides belegt noch nicht die tatsächlich gewählte API-Version. Dafür zählen der eingestellte Endpunkt beziehungsweise die Version und die Anfrageprotokolle. Eine Aktualisierung des Hauptrepositorys erneuert ältere bereitgestellte Prozesse nicht automatisch.
- Zu den Zeitplänen gehören Crontabs, Aufträge im Cloud Scheduler und weitere Automatisierungen. Daraus ergibt sich der nächste geplante Lauf, auch bei Quartalsprozessen ohne Ausführung seit dem Abschalttermin.
Ein ruhender Prozess schlägt nicht allein durch das Erreichen des Stichtags fehl. Der Fehler wird erst sichtbar, sobald die nächste Anfrage die abgeschaltete Version anspricht. Letzter erfolgreicher Lauf und nächster geplanter Lauf helfen, dieses verzögerte Problem zu erkennen.
Was gilt für Fremdwerkzeuge, die im Auftrag einer Agentur auf Google Ads zugreifen?
Für den API-Zugriff zählt das Projekt des OAuth-Clients. Bei einem vom Anbieter verwalteten OAuth-Client muss der Anbieter Projektfreigabe und API-Migration erledigen. Verwendet das Werkzeug stattdessen einen agentureigenen Client, bleibt die Zuständigkeit für dieses Projekt bei der Agentur. Das Integrationsverzeichnis sollte diese Aufteilung festhalten. Gültige Zugangsdaten und Berechtigungen am Kundenkonto bleiben in beiden Fällen erforderlich.
Quellen
- Google Ads: neues Anmeldeverfahren
- Google Ads API: Umstellung des Entwicklertokens
- Google Ads API: Erinnerung an die v22-Abschaltung
Quellen geprüft: 26. Oktober 2026.
Passend dazu
