Google Ads API: dostęp projektu Cloud i koniec v22 7 października 2026
Spis treści
We wrześniu 2026 roku zbiegają się dwie zmiany Google Ads API. Zarządzanie dostępem przechodzi do projektów Google Cloud, a wersja API v22 ma zakończyć działanie 7 października. Są to niezależne warunki. Zatwierdzony projekt nie przedłuża życia starej wersji API, a nowsza biblioteka nie nadaje dostępu produkcyjnego projektowi bez odpowiedniej zgody. [1, 2, 3]
Liczy się projekt powiązany z uwierzytelnianiem
Nowy model Google wiąże poziom dostępu z projektem Cloud używanym do uwierzytelniania. Przy logowaniu użytkownika jest to projekt klienta OAuth, a przy koncie usługi projekt będący właścicielem tego konta. Dotychczasowe poziomy przeniesiono na podstawie niedawnego użycia API. Sam od dawna zatwierdzony token programisty nie dowodzi więc poprawnej konfiguracji wszystkich projektów organizacji. [1, 2]
Przykładowa agencja ma codzienny system raportowy i drugą aplikację używaną tylko podczas okazjonalnych migracji. Obie wcześniej korzystały z tego samego zatwierdzonego tokenu, lecz ich dane uwierzytelniające należą do różnych projektów. Działający raport dzienny niewiele mówi o gotowości drugiej aplikacji. Spis integracji wymaga projektu powiązanego z uwierzytelnianiem, a nie tylko identyfikatora konta menedżera.
Trzy osobne warstwy
| Warstwa | Pytanie kontrolne |
|---|---|
| Uwierzytelnianie | Który użytkownik lub które konto usługi wysyła żądanie? |
| Dostęp API | Jaki poziom dostępu ma powiązany projekt Cloud? |
| Wersja API | Czy żądanie trafia do obsługiwanej wersji? |
Uprawnienia na koncie klienta pozostają kolejnym warunkiem. Tabela określa kolejność analizy, a nie gwarancję powodzenia każdej operacji. Pozwala uniknąć traktowania błędu wersji jak problemu z hasłem albo przebudowy kampanii z powodu brakującej zgody dla projektu.
Co zapisać po nieudanym żądaniu
Google dokumentuje błąd CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION w v25, gdy projekt z dostępem testowym wywołuje konto produkcyjne. Starsze wersje używają w tej sytuacji ACTION_NOT_PERMITTED. Aktualna strona pomocy opisuje również problemy przejściowe dotyczące części nowo zatwierdzonych projektów. Widoczna zgoda i odrzucone żądanie wymagają więc analizy, a nie natychmiastowego wniosku o błędnych danych logowania. [2]
Rejestr integracji – przykładowe pola
Aplikacja i odpowiedzialny zespół
Numer projektu Cloud
Metoda uwierzytelniania i identyfikator danych dostępowych
Konto docelowe: testowe lub produkcyjne
Wersja API widoczna w żądaniach
Dokładny kod błędu i identyfikator żądania
Czas ostatniego poprawnego wykonania
Rejestr potrzebuje identyfikatorów, a nie tajnych wartości. Token odświeżania, klucz prywatny i sekret klienta nie powinny trafiać do arkusza obsługi incydentów. W przykładowej agencji taki zapis odróżnia zapomniany proces miesięczny od działającego raportu dziennego bez zmiany konfiguracji kampanii.
Termin v22 pozostaje niezależny
Zapowiedź Google wskazuje, że żądania v22 zaczną kończyć się błędem 7 października 2026 roku. Metryki API w Cloud Console pomagają znaleźć niedawno wywoływane metody; nazwa metody zawiera wersję. Uzupełnia to przeszukiwanie kodu, ponieważ stary wdrożony proces może nadal działać po aktualizacji głównego repozytorium. [3]
Przegląd obejmuje zaplanowane eksporty, przesyłanie konwersji, skrypty utrzymaniowe i rzadko wykonywane zadania administracyjne. Poprawne odświeżenie panelu nie wystarcza, jeżeli import nocny nadal korzysta z v22. Migrację należy oceniać według rzeczywiście wykonywanych operacji. Odczyt danych i operacje zapisujące wymagają osobnych prób.
Kontrolowana zmiana zamiast kilku równoległych napraw
Praktyczna kolejność obejmuje najpierw zapisanie stanu dostępu projektu, następnie aktualizację biblioteki i odpowiedniego kodu żądań, a na końcu sprawdzenie reprezentatywnych operacji. Jeśli jest to możliwe, odrębne konto testowe umożliwia próby przed zapisem produkcyjnym. Dokumentacja powinna rozróżniać walidację od wykonanej zmiany i przechowywać identyfikatory utworzonych zasobów.
Dotychczasowy nagłówek developer token jest według Google obecnie opcjonalny i ignorowany. Google zaleca jego usunięcie i zapowiada odrzucanie w przyszłej wersji głównej. Bez osobnego ogłoszenia nie należy utożsamiać tego przyszłego kroku z terminem wyłączenia v22. Zaktualizowane biblioteki obsługują żądania bez tego tokenu. [1, 2]
Odpowiedzialność jest częścią utrzymania
Kontakty z rolami Owner i Editor w projekcie stają się również istotne dla komunikatów o usłudze. Technicznie działająca integracja może być źle utrzymywana, jeśli powiadomienia trafiają do byłych pracowników. Przegląd odpowiedzialności i alarmów powinien towarzyszyć migracji technicznej. Powiązany artykuł o passkeys dotyczy innej warstwy: konta człowieka stojącego za autoryzacją. Nie zastępuje kontroli dostępu projektu opisanej tutaj.
Powiązane narzędzie
GoogleAds – eksplorator zapytań GAQL
Wymóg passkey w Google Ads API: czego dotyczy i jak znaleźć zapomniane autoryzacje
Pytania i odpowiedzi
Jak znaleźć rzadko uruchamiane procesy, które wciąż korzystają z v22?
Przez kilka źródeł, bo każde widzi tylko część obrazu:
- Metryki API w Cloud Console, osobno dla każdego projektu. Pokazują tylko wywołania z wybranego projektu i tylko z wybranego okresu; kwartalny eksport, który w tym okresie nie działał, nie pojawia się w nich, a drugi projekt pojawia się dopiero po jego wybraniu.
- Zależności wdrożonych procesów. Każda wersja bibliotek klienckich obsługuje określony zestaw wersji API, a stary plik blokady zależności (lockfile) albo stary obraz kontenera trzyma proces przy wersji aktualnej w chwili budowania, nawet jeśli główne repozytorium dawno zaktualizowano.
- Same harmonogramy: crontaby, zadania w Cloud Scheduler i automatyzacje, które zespół kiedyś skonfigurował. Z nich wynika, który proces w ogóle uruchomi się jeszcze raz przed 7 października.
To, czego nie ma w żadnym z tych źródeł, ujawni się najpóźniej w dniu wyłączenia jako błąd. Dlatego warto zapisywać w rejestrze integracji dla każdego procesu czas ostatniego poprawnego wykonania; wpis sprzed kilku miesięcy to kandydat właśnie na taki przypadek.
Jak wygląda sytuacja zewnętrznych narzędzi, które korzystają z Google Ads w imieniu agencji?
Przy logowaniu użytkownika liczy się projekt klienta OAuth, a w przypadku zewnętrznego narzędzia należy on do dostawcy. O tym, czy połączenie dalej działa, decydują więc jego poziom dostępu i jego migracja z v22; agencja nie naprawi tego sama, może jedynie odnotować to w rejestrze integracji i zapytać dostawcę.
Źródła
- 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
Źródła sprawdzone: 24 września 2026.