{"id":9363,"date":"2026-08-11T09:55:00","date_gmt":"2026-08-11T07:55:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9363"},"modified":"2026-10-24T02:46:20","modified_gmt":"2026-10-24T00:46:20","slug":"refresh-tokeny-amazon-ads-wygasanie-po-365-dniach-od-30-lipca-bez","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-marketing-pl\/refresh-tokeny-amazon-ads-wygasanie-po-365-dniach-od-30-lipca-bez\/","title":{"rendered":"Refresh tokeny Amazon Ads: limit 365 dni i skuteczne monitorowanie wa\u017cno\u015bci"},"content":{"rendered":"

Refresh tokeny Amazon Ads: limit 365 dni i skuteczne monitorowanie wa\u017cno\u015bci<\/h2>\n

Od 30 lipca 2026 r. nowo wydane refresh tokeny dla uprawnie\u0144 reklamowych Amazon Ads maj\u0105 sta\u0142y okres wa\u017cno\u015bci: 365 dni od zgody reklamodawcy. Wymiana na nowe access tokeny nie rozpoczyna tego okresu od nowa. Lokalny rejestr umo\u017cliwia wcze\u015bniejsze ostrzeganie, a monitoring b\u0142\u0119d\u00f3w wykrywa cofni\u0119te lub uniewa\u017cnione dane dost\u0119powe tak\u017ce przed planowanym terminem.<\/p>\n

Access token uwierzytelnia \u017c\u0105dania API i zwykle jest wa\u017cny przez 60 minut. Refresh token pozwala uzyska\u0107 kolejne access tokeny bez ponawiania dialogu zgody przy ka\u017cdej wymianie.<\/p>\n

1. Zakres regu\u0142y 365 dni<\/h2>\n

Amazon stosuje regu\u0142\u0119 do token\u00f3w wydanych od 30 lipca 2026 r. dla advertising::campaign_management i advertising::audiences. Wcze\u015bniejsze tokeny nie otrzymuj\u0105 wskutek tej zmiany sta\u0142ej daty wyga\u015bni\u0119cia, ale nadal mog\u0105 zosta\u0107 cofni\u0119te lub uniewa\u017cnione z innych powod\u00f3w. Decyduje wydanie tokena, a nie sam dzie\u0144 pod\u0142\u0105czenia konta reklamowego do integracji.<\/p>\n

Sta\u0142y okres zaczyna si\u0119 od zgody. Wymiana refresh tokena zwraca nowy access token oraz ten sam refresh token; nowa zgoda jest osobn\u0105 operacj\u0105. Dostawcy OAuth stosuj\u0105 r\u00f3\u017cne zasady, wi\u0119c przesuwanie wa\u017cno\u015bci nie jest og\u00f3ln\u0105 cech\u0105 refresh token\u00f3w. Regu\u0142 Amazon Ads nie nale\u017cy te\u017c uto\u017csamia\u0107 z zasadami autoryzacji Selling Partner API.<\/p>\n

Aktualny przewodnik Amazon Ads zaleca monitorowanie wieku token\u00f3w i ponown\u0105 autoryzacj\u0119 z wyprzedzeniem. Przewodnik nie potwierdza og\u00f3lnego twierdzenia, \u017ce Amazon nigdy nie wysy\u0142a e-maili, ostrze\u017ce\u0144 w konsoli ani innych przypomnie\u0144. Monitoring operacyjny powinien dzia\u0142a\u0107 niezale\u017cnie od za\u0142o\u017conego powiadomienia dostawcy.<\/p>\n

\"Zgoda
Zgoda wyznacza sta\u0142y termin planowania. Kolejne od\u015bwie\u017cenia nie przed\u0142u\u017caj\u0105 wa\u017cno\u015bci. Nieznane dane wymagaj\u0105 wyja\u015bnienia; tokeny legacy nie maj\u0105 sta\u0142ego terminu wed\u0142ug tej regu\u0142y.<\/figcaption><\/figure>\n

2. Rejestr autoryzacji zamiast warto\u015bci token\u00f3w<\/h2>\n

Przyk\u0142ad PostgreSQL przechowuje jeden wiersz na niezale\u017cnie zarz\u0105dzan\u0105 autoryzacj\u0119. authorization_id jest wewn\u0119trznym sta\u0142ym identyfikatorem, a client_id oznacza aplikacj\u0119. Kilka aplikacji lub niezale\u017cnych autoryzacji tego samego reklamodawcy wymaga osobnych wierszy. Sama nazwa konta nie identyfikuje jednoznacznie autoryzacji. W\u0142a\u015bciwe refresh tokeny i client secrets nale\u017c\u0105 do chronionego magazynu sekret\u00f3w, poza t\u0105 tabel\u0105 i tre\u015bci\u0105 alert\u00f3w.<\/p>\n

Pole policy rozr\u00f3\u017cnia fixed_365, legacy i unknown. Wiersze legacy nie otrzymuj\u0105 wyliczonego terminu. Brak dowod\u00f3w oznacza unknown i powoduje ostrze\u017cenie, zamiast tworzy\u0107 fikcyjn\u0105 dat\u0119 zgody. Dla fixed_365 pole consent_date zawiera kalendarzow\u0105 dat\u0119 UTC zarejestrowanej zgody, a token_issued_at rzeczywisty czas wydania. Klasyfikacja w pobli\u017cu daty granicznej wymaga wiarygodnego dziennika autoryzacji.<\/p>\n

CREATE TABLE amazon_ads_token_ledger (\n    authorization_id text PRIMARY KEY,\n    client_id        text NOT NULL,\n    account_name     text NOT NULL,\n    policy           text NOT NULL\n                     CHECK (policy IN ('fixed_365', 'legacy', 'unknown')),\n    consent_date     date,\n    token_issued_at  timestamptz,\n    expires_on       date GENERATED ALWAYS AS (\n        CASE WHEN policy = 'fixed_365' THEN consent_date + 365 END\n    ) STORED,\n    last_refresh_ok  timestamptz,\n    owner_email      text NOT NULL,\n    status           text NOT NULL DEFAULT 'active'\n                     CHECK (status IN ('active', 'revoked')),\n    CHECK (policy <> 'fixed_365' OR\n           (consent_date IS NOT NULL AND token_issued_at IS NOT NULL)),\n    CHECK (policy <> 'fixed_365' OR\n           (token_issued_at AT TIME ZONE 'UTC')::date >= DATE '2026-07-30'),\n    CHECK (policy <> 'legacy' OR\n           (token_issued_at IS NOT NULL AND\n            (token_issued_at AT TIME ZONE 'UTC')::date < DATE '2026-07-30'))\n);\n\nCREATE INDEX ON amazon_ads_token_ledger (expires_on)\nWHERE status = 'active';\n<\/code><\/pre>\n
expires_on jest zachowawczym terminem planowania: data zgody plus 365 dni. Sama data nie okre\u015bla dok\u0142adnej sekundy wyga\u015bni\u0119cia na serwerach Amazona. Skrypt traktuje pocz\u0105tek tego dnia UTC jako krytyczn\u0105 granic\u0119 planowania, dlatego odnowienie powinno nast\u0105pi\u0107 wcze\u015bniej. Kolumna generowana zapewnia zgodno\u015b\u0107 obliczenia z zapisanymi danymi; b\u0142\u0119dne daty wej\u015bciowe nadal daj\u0105 b\u0142\u0119dne terminy.<\/p>\n
3. Skrypt z jednoznacznymi stanami b\u0142\u0119du<\/h2>\n
Przyk\u0142ad dla Python 3 wymaga Psycopg 3. Rola bazy potrzebuje wy\u0142\u0105cznie SELECT dla rejestru. Parametry po\u0142\u0105czenia pochodz\u0105 z ADS_LEDGER_DSN; dane dost\u0119powe mog\u0105 korzysta\u0107 z chronionego pliku hase\u0142 PostgreSQL lub odpowiedniej konfiguracji us\u0142ugi. Przyk\u0142ad ogranicza czas po\u0142\u0105czenia i zapytania oraz nie wypisuje DSN ani warto\u015bci token\u00f3w przy b\u0142\u0119dach.<\/p>\n
#!\/usr\/bin\/env python3\nimport os\nimport sys\nimport psycopg\n\nWARN_DAYS = 60\nQUERY = """\nSELECT authorization_id, account_name, policy, expires_on,\n       expires_on - CURRENT_DATE AS days_left, owner_email\nFROM amazon_ads_token_ledger\nWHERE status = 'active'\n  AND (policy = 'unknown' OR expires_on <= CURRENT_DATE + %s)\nORDER BY expires_on NULLS FIRST, authorization_id\n"""\n\ndef render(rows):\n    result = 0\n    for aid, name, policy, expires, days, owner in rows:\n        if policy == 'unknown':\n            state = 'UNKNOWN: authorization metadata needs review'\n            result = 2\n        elif days <= 0:\n            state = 'DUE: planning deadline reached; check authorization'\n            result = max(result, 1)\n        else:\n            state = f'WARNING: {days} days to planning deadline'\n        print(f'{aid} | {name} | {state} | deadline={expires} | owner={owner}')\n    return result\n\ndef main():\n    dsn = os.environ.get('ADS_LEDGER_DSN')\n    if not dsn:\n        print('CHECK FAILED: ADS_LEDGER_DSN is missing', file=sys.stderr)\n        return 2\n    try:\n        with psycopg.connect(dsn, connect_timeout=5,\n                options='-c timezone=UTC -c statement_timeout=5000') as conn:\n            rows = conn.execute(QUERY, (WARN_DAYS,)).fetchall()\n    except psycopg.Error as exc:\n        # No DSN, credentials or token contents in diagnostic output.\n        print(f'CHECK FAILED: {type(exc).__name__}', file=sys.stderr)\n        return 2\n    return render(rows)\n\nif __name__ == '__main__':\n    sys.exit(main())\n<\/code><\/pre>\n
Kod zako\u0144czenia 0 oznacza brak stanu krytycznego; wcze\u015bniejsze ostrze\u017cenia nadal generuj\u0105 tekst. Kod 1 sygnalizuje osi\u0105gni\u0119cie terminu planowania. Kod 2 oznacza nieznane dane autoryzacji albo nieudan\u0105 kontrol\u0119. Warstwa monitoringu musi faktycznie odbiera\u0107 te kody. Pr\u00f3g 60 dni jest regulowanym buforem organizacyjnym, a nie wymogiem Amazona ani uniwersalnym zmierzonym czasem akceptacji.<\/p>\n
4. Harmonogram i dostarczenie powiadomie\u0144<\/h2>\n
# Service-user crontab; working local mail transport required.\nMAILTO=ads-ops@example.com\nADS_LEDGER_DSN="dbname=ops user=ads_ledger_reader"\n17 6 * * * \/opt\/ads\/venv\/bin\/python \/opt\/ads\/token_ledger_check.py\n<\/code><\/pre>\n
\u015acie\u017cki i rola bazy s\u0105 przyk\u0142adami wdro\u017cenia. Prywatne \u015brodowisko Pythona musi zawiera\u0107 Psycopg, a lokalne uwierzytelnianie pozwala\u0107 na u\u017cycie roli tylko do odczytu. Cron uruchamia zadanie o 06:17 w skonfigurowanej strefie harmonogramu; obliczenia dat w SQL u\u017cywaj\u0105 jawnie UTC. MAILTO wymaga dzia\u0142aj\u0105cego lokalnego transportu poczty i sprawdzonego odbiorcy. Sam skrypt nie wysy\u0142a e-maili, a owner_email opisuje odpowiedzialno\u015b\u0107 i nie jest automatycznym adresem dostarczenia.<\/p>\n
Utrzymuj\u0105cy si\u0119 stan mo\u017ce powodowa\u0107 codzienne przypomnienie. Eskalacja, potwierdzenie odbioru i ograniczanie liczby wiadomo\u015bci nale\u017c\u0105 do otaczaj\u0105cego monitoringu. Potrzebny jest niezale\u017cny sygna\u0142 dzia\u0142ania albo kontrola pomini\u0119tych uruchomie\u0144, poniewa\u017c zatrzymany harmonogram nie zg\u0142osi w\u0142asnej awarii. Pole last_refresh_ok pomaga tylko wtedy, gdy proces od\u015bwie\u017cania aktualizuje warto\u015b\u0107, a osobna kontrola sprawdza aktualno\u015b\u0107.<\/p>\n
5. Odnowienie i obs\u0142uga b\u0142\u0119d\u00f3w<\/h2>\n
Wed\u0142ug Amazona niewa\u017cny refresh token powoduje HTTP 400 z invalid_grant. Zadanie raportowe powinno zg\u0142osi\u0107 b\u0142\u0105d, zamiast zast\u0119powa\u0107 prawid\u0142owe raporty pustymi danymi. B\u0142\u0119dy sieci mog\u0105 uzasadnia\u0107 ograniczone ponowienia; powtarzanie \u017c\u0105dania nie naprawia niewa\u017cnego grantu. Odzyskanie dost\u0119pu wymaga nowego authorization grant przez procedur\u0119 zgody. Udane odnowienie obejmuje sp\u00f3jn\u0105 aktualizacj\u0119 sekretu i rejestru, a nast\u0119pnie rzeczywist\u0105 wymian\u0119 na access token oraz minimalne dozwolone sprawdzenie API.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Co oznacza brak pierwotnej daty zgody?<\/h3>\n
Nieprzezroczysty ci\u0105g refresh tokena nie jest wiarygodnym zapisem daty zgody. Dost\u0119pne dzienniki autoryzacji i dokumentacja pod\u0142\u0105czenia mog\u0105 ustali\u0107 dat\u0119; bez takiego dowodu wiersz pozostaje unknown. Zaplanowana ponowna autoryzacja mo\u017ce utworzy\u0107 now\u0105 zarejestrowan\u0105 zgod\u0119. Szacowana data nie powinna bez ostrze\u017cenia zmienia\u0107 nieznanego stanu na prawid\u0142owy.<\/p>\n
Czy tokeny legacy wymagaj\u0105 corocznego odnowienia wed\u0142ug tej regu\u0142y?<\/h3>\n
Token\u00f3w wydanych przed 30 lipca 2026 r. nie obejmuje sta\u0142y roczny termin z podlinkowanej regu\u0142y Ads. Cofni\u0119cie uprawnie\u0144 i inne przyczyny uniewa\u017cnienia nadal wymagaj\u0105 monitoringu. Nowo wydany token zast\u0119pczy wymaga klasyfikacji na podstawie aktualnych dowod\u00f3w wydania i zgody; zwyk\u0142e od\u015bwie\u017cenie access tokena nie jest now\u0105 zgod\u0105.<\/p>\n<\/div>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n