English
Deutsch
PolskiGoogle Ads API: Cloud-Projekt-Zugriff und der v22-Stichtag am 7. Oktober 2026
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
Im September 2026 treffen zwei Änderungen der Google Ads API zusammen. Die Zugriffsverwaltung wechselt zu Google-Cloud-Projekten. Gleichzeitig soll API-Version v22 am 7. Oktober abgeschaltet werden. Beide Bedingungen sind getrennt zu prüfen: Ein freigegebenes Projekt verlängert keine veraltete API-Version, und eine neuere Bibliothek erteilt einem nicht freigegebenen 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 kürzlich erfolgter API-Nutzung übertragen. Ein seit Jahren genehmigter Entwicklertoken beweist deshalb nicht, dass jedes Projekt einer Organisation die erwartete Freigabe besitzt. [1, 2]
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. Sie 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 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; sie beweisen nicht sofort 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
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.
- Die Abhängigkeiten der bereitgestellten Prozesse. Jede Version der Clientbibliotheken unterstützt eine bestimmte Auswahl an API-Versionen, und ein altes Lockfile oder ein altes Container-Image hält einen Prozess auf der Version, die beim Bauen aktuell war, auch wenn das Hauptrepository längst aktualisiert ist.
- Die Zeitpläne selbst: Crontabs, Aufträge im Cloud Scheduler und Automatisierungen, die ein Team einmal eingerichtet hat. Aus ihnen ergibt sich, welcher Prozess zwischen jetzt und dem 7. Oktober überhaupt noch einmal läuft.
Was in keiner dieser Quellen auftaucht, zeigt sich spätestens am Stichtag als Fehler. Deshalb lohnt es sich, im Integrationsverzeichnis für jeden Prozess den Zeitpunkt des letzten erfolgreichen Laufs festzuhalten; ein Eintrag, der Monate zurückliegt, ist ein Kandidat für genau diesen Fall.
Was gilt für Fremdwerkzeuge, die im Auftrag einer Agentur auf Google Ads zugreifen?
Bei einer Nutzeranmeldung zählt das Projekt des OAuth-Clients, und das gehört bei einem fremden Werkzeug dem Anbieter. Dessen Zugriffsstufe und dessen Umstellung von v22 entscheiden also, ob die Verbindung weiterläuft; die Agentur kann das nicht selbst beheben, sondern nur im Verzeichnis festhalten und beim Anbieter erfragen.
Quellen
- Google Ads: New onboarding experience, 10 September 2026
- Google Ads API: Developer-token transition and troubleshooting
- Google Ads API v22 sunset reminder, 2 September 2026
Quellen geprüft: 24. September 2026.
Passend dazu
