Google Ads API Autentifikacija: OAuth, Service Account i Developer Token [2026]

Moja Basic Access prijava za Google Ads API prošla je pregled za par sati umesto uobičajenih dana - tačne korake opisao sam u vodiču za Basic Access. Ali odobren token ne znači ništa dok ne prođete kroz auth handshake, a to je sasvim odvojen problem - prvi put me je to sasekao na tokenu za Google Merchant Center koji je umro usred skripta, bez ijednog upozorenja.

Ovaj vodič pokriva deo koji niko čisto ne objasni: OAuth2 desktop naspram web toka, zamku od 7 dana, šta je developer token header stvarno u odnosu na OAuth token, kad je service account zaista pravi alat (a kad to samo izgleda tako), i test od dva minuta u Python-u kojim proverite da ceo lanac radi pre nego što na njemu gradite bilo šta.

Tri (plus jedan) sloja Google Ads API autentifikacije

Najčešća zabuna kod početnika: developer token nije OAuth token, i njegovo odobrenje samo po sebi ne autentifikuje ništa. To su dva potpuno nezavisna kredencijala koja moraju biti prisutna na svakom pozivu, plus treći koji je bitan tek kad radite kroz manager nalog.

Sam developer token - kako se generiše, i nivoi pristupa Test / Explorer / Basic / Standard koji određuju šta može da poziva - pokriven je u celini u vodiču za Basic Access. Ovaj post pretpostavlja da već imate token (bilo koji nivo radi za testiranje) i fokusira se na to da ostali slojevi rade kako treba.

OAuth2: desktop tok naspram web toka

Google Ads API podržava dva OAuth2 toka, i izbor pravog štedi celu klasu bagova kasnije. Prema Google-ovoj dokumentaciji o OAuth internom radu, desktop (installed app) tok ima offline pristup - mogućnost da se token osveži bez korisnika koji sedi ispred ekrana - uključen po default-u: eksplicitno ga ne morate tražiti. Web application tok to nema; treba mu eksplicitan access_type=offline parametar na auth zahtevu, ili refresh token uopšte ne stiže.

Za solo operatera ili agenciju koja vodi interne skriptove - izvlačenje reportova, provere trošenja budžeta, promene bidova - desktop tok je pravi default. Njega pokrećem za svaki klijentski nalog pod sopstvenim manager nalogom. Web tok je za drugi slučaj: aplikaciju sa ekranom za login koju koristi treća strana.

Ako ste već prošli kroz OAuth consent screen radi verifikacije brenda - korak 4 u vodiču za Basic Access - prepoznaćete ovaj ekran. Isti je; sad ste tu iz drugog razloga.

Zamka: Testing mode ubija refresh token za 7 dana

Ovo je dokumentovano, ali se lako previdi. Prema Google-ovoj OAuth 2.0 dokumentaciji, Cloud projekat sa External tipom korisnika i Testing statusom objave izdaje refresh tokene koji ističu za 7 dana - bez mejla, bez upozorenja, ničega. Sledeći poziv jednostavno padne sa invalid_grant ("Token has been expired or revoked"), i ako skript radi bez nadzora preko noći, saznajete tek kad report ne stigne. Tačno ovako mi je umro jedan token za Google Merchant Center, a ceo taj incident i rešenje opisao sam u vodiču za Google API pristupe za agencije. Ako je vaš projekat isti onaj koji ste već gurnuli u In production radi verifikacije brenda (korak 4 iz vodiča za Basic Access), ovo je već rešeno. Ako niste, proverite sad: Cloud Console → APIs and services → OAuth consent screen → tab Audience.

Developer token header + login-customer-id

Još dve stvari se stalno mešaju jedna sa drugom, i nijedna nije OAuth koncept.

Developer token nije header koji dobijate iz OAuth toka - to je fiksan string iz API Center-a vašeg manager naloga (22 karaktera u mojim nalozima), i ide na svaki zahtev kao developer-token HTTP/gRPC header. Identifikuje aplikaciju, ne osobu koja poziva, i ista je vrednost bez obzira koji je Google nalog autentifikovao poziv.

login-customer-id je bitan tek kad vaš autentifikovan nalog ima pristup manager (MCC) nalogu. Ako pozivate API da uradite nešto na klijentskom nalogu ispod tog MCC-a, morate Google-u reći u kontekstu kog naloga radite - postavite login-customer-id header na ID MCC-a. Preskočite to i dobijate USER_PERMISSION_DENIED: "the authorized customer does not have access to the operating customer", iako u Google Ads interfejsu jasno imate pristup.

Service account - deo koji quick reference preskače

Google-ov sopstveni vodič za service account deluje jednostavno: napravite service account, preuzmite JSON ključ, ulogujte se u Google Ads kao admin, idite na Admin → Access and security, dodajte email service account-a kao korisnika, postavite json_key_file_path u konfiguraciji. Četiri koraka, gotovo.

Kad se isplati: server-to-server automatizacija bez čoveka u petlji za svako osvežavanje tokena, i - korisno - pristup koji ne pukne onog dana kad zaposleni ode, jer nije vezan ni za čiji lični Google nalog. Prema Google-ovom vodiču, jedan email service account-a može se dodati na do 20 Google Ads naloga; iznad toga, preporuka je da se doda kroz manager nalog.

Kad se ne isplati: solo operater ili mali tim bez Workspace domena. To je i moja stvarna postavka - svaki skript koji pokrećem prema Google Ads API-ju koristi desktop OAuth tok opisan gore, ne service account, jer se jednostavnije podešava i ne zahteva podizanje domain-wide delegacije za automatizaciju jedne osobe.

google-ads.yaml: šta fajlu stvarno treba

Koji god tok da koristite, Python client biblioteka čita sve iz jednog YAML fajla. Evo kako izgleda - zamenite svaku vrednost, naravno, ovo nije stvarna konfiguracija:

developer_token: "UPIŠI_DEVELOPER_TOKEN_OVDE"
client_id: "UPIŠI_OAUTH2_CLIENT_ID_OVDE"
client_secret: "UPIŠI_OAUTH2_CLIENT_SECRET_OVDE"
refresh_token: "UPIŠI_REFRESH_TOKEN_OVDE"
login_customer_id: "1234567890"   # MCC ID, samo cifre, bez crtica; izostavite ovaj red za samostalan nalog
use_proto_plus: True

Dve stvari vredne isticanja: login_customer_id je MCC ID bez crtica, i mora se postaviti samo ako pozivate kroz manager nalog - izostavite ga za samostalan nalog. A use_proto_plus: True nije opciona kozmetika; client biblioteka zahteva ovo polje u konfiguraciji, i njegovo odsustvo pravi konfuzne greške tipova koje s autentifikacijom nemaju veze.

Proveri da radi: minimalan Python test

Pre nego što na ovome bilo šta gradite, proverite da ceo lanac - OAuth2, developer token, login-customer-id - stvarno radi. Isti princip kao testiranje na Explorer pristupu pre prijave za Basic: prvo dokažite da lanac radi na najmanjem mogućem pozivu.

# 1) Jednokratno: generiši refresh token (desktop OAuth tok)
from google_auth_oauthlib.flow import InstalledAppFlow

SCOPES = ["https://www.googleapis.com/auth/adwords"]
flow = InstalledAppFlow.from_client_secrets_file("client_secret.json", scopes=SCOPES)
credentials = flow.run_local_server(port=8080, prompt="consent")
print(credentials.refresh_token)  # nalepi ovo u google-ads.yaml

# 2) Prvi poziv: da li konekcija stvarno radi?
from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml")
ga_service = client.get_service("GoogleAdsService")

query = "SELECT customer.id, customer.descriptive_name FROM customer LIMIT 1"
response = ga_service.search(customer_id="9876543210", query=query)

for row in response:
    print(row.customer.descriptive_name)

Ako to vrati ime naloga, svaki sloj - OAuth2, developer token, login-customer-id - pravilno je povezan. Ako padne, greška koju dobijete nazad kaže tačno koji sloj popraviti; vidi tabelu ispod.

Česte greške i šta ih stvarno izaziva

Sva četiri opisa gore citirana su iz Google-ove zvanične dokumentacije o čestim greškama. Uzroci i rešenja su ono na šta sam stvarno naleteo povezujući ovo za klijentske naloge.

Najčešća pitanja