{"id":9362,"date":"2026-08-11T08:40:00","date_gmt":"2026-08-11T06:40:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9362"},"modified":"2026-10-24T02:46:20","modified_gmt":"2026-10-24T00:46:20","slug":"amazon-ads-refresh-tokens-365-tage-laufzeit-seit-dem-30-juli-keine","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/amazon-ads-refresh-tokens-365-tage-laufzeit-seit-dem-30-juli-keine\/","title":{"rendered":"Amazon Ads Refresh Tokens: 365-Tage-Frist und zuverl\u00e4ssige Ablauf\u00fcberwachung"},"content":{"rendered":"

Amazon Ads Refresh Tokens: 365-Tage-Frist und zuverl\u00e4ssige Ablauf\u00fcberwachung<\/h2>\n

Seit dem 30. Juli 2026 gilt f\u00fcr neu ausgestellte Refresh Tokens der Amazon-Ads-Werbeberechtigungen eine feste Laufzeit: 365 Tage ab Einwilligung des Advertisers. Der Tausch gegen neue Access Tokens startet diese Frist nicht erneut. Ein lokales Register erm\u00f6glicht Vorwarnungen; erg\u00e4nzendes Fehlermonitoring erkennt widerrufene oder anderweitig ung\u00fcltige Zugangsdaten auch vor dem geplanten Termin.<\/p>\n

Ein Access Token authentifiziert API-Anfragen und gilt normalerweise 60 Minuten. Ein Refresh Token beschafft neue Access Tokens, ohne bei jedem Tausch erneut den Einwilligungsdialog durchlaufen zu m\u00fcssen.<\/p>\n

1. F\u00fcr welche Tokens die 365-Tage-Regel gilt<\/h2>\n

Amazon wendet die Regel auf ab dem 30. Juli 2026 ausgestellte Tokens f\u00fcr advertising::campaign_management und advertising::audiences an. Fr\u00fchere Tokens erhalten durch diese \u00c4nderung kein festes Ablaufdatum, bleiben aber widerrufbar und k\u00f6nnen aus anderen Gr\u00fcnden ung\u00fcltig werden. Entscheidend ist die Token-Ausstellung, nicht allein der Aufnahmezeitpunkt eines Werbekontos in eine Integration.<\/p>\n

Die feste Laufzeit beginnt mit der Einwilligung. Ein Refresh-Tausch liefert ein neues Access Token und dasselbe Refresh Token; eine neue Einwilligung ist ein anderer Vorgang. OAuth-Anbieter verwenden unterschiedliche Regeln. Eine gleitende Laufzeit ist deshalb keine allgemeine Eigenschaft von Refresh Tokens. Au\u00dferdem sind die Amazon-Ads-Regeln von den Autorisierungsregeln der Selling Partner API zu unterscheiden.<\/p>\n

Der aktuelle Amazon-Ads-Leitfaden empfiehlt vorausschauende Alters\u00fcberwachung und erneute Autorisierung. Eine pauschale Aussage, Amazon verschicke niemals E-Mails, Konsolenhinweise oder andere Erinnerungen, ist durch diesen Leitfaden nicht belegt. Die betriebliche \u00dcberwachung sollte unabh\u00e4ngig von einer angenommenen Anbieterbenachrichtigung funktionieren.<\/p>\n

\"Die
Die Einwilligung bestimmt den festen Planungstermin. Refresh-Aufrufe verl\u00e4ngern die Frist nicht. Unbekannte Angaben ben\u00f6tigen Kl\u00e4rung; Legacy-Tokens haben nach dieser Regel keine feste Frist.<\/figcaption><\/figure>\n

2. Ein Register f\u00fcr Autorisierungen statt Token-Inhalte<\/h2>\n

Das PostgreSQL-Beispiel speichert eine Zeile je unabh\u00e4ngig verwalteter Autorisierung. authorization_id ist eine interne stabile Kennung; client_id bezeichnet die Anwendung. Mehrere Anwendungen oder Berechtigungen f\u00fcr denselben Advertiser ben\u00f6tigen getrennte Zeilen. Ein Kontoname allein ist keine eindeutige Autorisierungskennung. Echte Refresh Tokens und Client Secrets geh\u00f6ren in gesch\u00fctzte Geheimnisverwaltung, au\u00dferhalb dieser Tabelle und der Alarmausgabe.<\/p>\n

Das Feld policy unterscheidet fixed_365, legacy und unknown. Legacy-Zeilen erhalten kein berechnetes Ablaufdatum. Fehlende Belege geh\u00f6ren unter unknown und l\u00f6sen eine Meldung aus, statt ein erfundenes Einwilligungsdatum zu erzeugen. F\u00fcr fixed_365 enth\u00e4lt consent_date das UTC-Kalenderdatum der protokollierten Einwilligung und token_issued_at den tats\u00e4chlichen Ausstellungszeitpunkt. F\u00fcr die Einordnung rund um den Stichtag ist ein verl\u00e4ssliches Autorisierungsprotokoll erforderlich.<\/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 ist ein konservativer Planungstermin: Einwilligungsdatum plus 365 Tage. Ein reiner Datumswert belegt keinen sekundengenauen Ablaufzeitpunkt auf Amazons Servern. Das Pr\u00fcfskript behandelt den Beginn dieses UTC-Tages als kritische Planungsgrenze; die Erneuerung geh\u00f6rt deshalb vor diesen Tag. Eine generierte Spalte h\u00e4lt die Rechnung konsistent mit den gespeicherten Eingaben. Falsche Ausgangsdaten ergeben weiterhin falsche Termine.<\/p>\n
3. Pr\u00fcfskript mit ausdr\u00fccklichen Fehlerzust\u00e4nden<\/h2>\n
Dieses Python-3-Beispiel ben\u00f6tigt Psycopg 3. Die Datenbankrolle braucht lediglich SELECT auf das Register. Die Verbindungsangaben stammen aus ADS_LEDGER_DSN; Zugangsdaten k\u00f6nnen \u00fcber eine gesch\u00fctzte PostgreSQL-Passwortdatei oder passende Dienstkonfiguration bereitstehen. Das Beispiel begrenzt Verbindungs- und Abfragezeit und gibt bei Fehlern weder DSN noch Token-Inhalte aus.<\/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
Exit-Code 0 bedeutet, dass kein kritischer Zustand gefunden wurde; Vorwarnungen erzeugen trotzdem Ausgabe. Exit-Code 1 meldet einen erreichten Planungstermin. Exit-Code 2 steht f\u00fcr unbekannte Autorisierungsdaten oder eine fehlgeschlagene Pr\u00fcfung. Ein Monitoring-Wrapper muss diese Codes tats\u00e4chlich auswerten. Die 60-Tage-Schwelle ist ein anpassbarer organisatorischer Puffer, keine Amazon-Vorgabe und keine allgemein gemessene Freigabedauer.<\/p>\n
4. Zeitplan und Zustellung<\/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
Pfade und Datenbankrolle sind Beispiele f\u00fcr die Einrichtung. Die private Python-Umgebung ben\u00f6tigt Psycopg, und die lokale Anmeldung muss die lesende Rolle zulassen. Cron l\u00e4uft um 06:17 Uhr in der konfigurierten Zeitzone des Schedulers; die SQL-Datumsberechnung verwendet ausdr\u00fccklich UTC. MAILTO ben\u00f6tigt funktionierenden lokalen Mailtransport und einen gepr\u00fcften Empf\u00e4nger. Das Skript versendet selbst keine E-Mail. owner_email kennzeichnet lediglich die Zust\u00e4ndigkeit und ist keine automatische Zustelladresse.<\/p>\n
Solange ein Zustand besteht, kann die Ausgabe t\u00e4glich eine Erinnerung ausl\u00f6sen. Eskalation, Best\u00e4tigung und Begrenzung der Nachrichtenanzahl geh\u00f6ren in das umgebende Monitoring. Ein unabh\u00e4ngiges Lebenszeichen oder eine Kontrolle ausgebliebener L\u00e4ufe ist erforderlich, weil ein gestoppter Scheduler den eigenen Ausfall nicht melden kann. last_refresh_ok ist nur dann n\u00fctzlich, wenn der Refresh-Prozess das Feld aktualisiert und eine separate Aktualit\u00e4tspr\u00fcfung den Wert auswertet.<\/p>\n
5. Erneuerung und Fehlerbehandlung<\/h2>\n
Ein ung\u00fcltiges Refresh Token f\u00fchrt laut Amazon zu HTTP 400 mit invalid_grant. Ein Reporting-Job muss diesen Fehler melden, statt g\u00fcltige Berichte durch leere Daten zu ersetzen. Bei Netzwerkfehlern k\u00f6nnen begrenzte Wiederholungen sinnvoll sein; einen ung\u00fcltigen Grant reparieren Wiederholungen nicht. Die Wiederherstellung ben\u00f6tigt einen neuen Authorization Grant \u00fcber den Einwilligungsablauf. Nach erfolgreicher Erneuerung werden Geheimnis und Register konsistent aktualisiert; anschlie\u00dfend folgen ein echter Access-Token-Tausch und eine minimale berechtigte API-Pr\u00fcfung.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Was gilt bei unbekanntem urspr\u00fcnglichem Einwilligungsdatum?<\/h3>\n
Die undurchsichtige Refresh-Token-Zeichenfolge ist kein verl\u00e4sslicher Datumsnachweis. Vorhandene Autorisierungsprotokolle und Onboarding-Belege k\u00f6nnen das Datum belegen; andernfalls bleibt die Zeile unknown. Eine geplante Neuautorisierung kann eine neue protokollierte Einwilligung schaffen. Ein gesch\u00e4tztes Datum darf einen ungekl\u00e4rten Zustand jedoch nicht stillschweigend als gesund ausweisen.<\/p>\n
Ben\u00f6tigen Legacy-Tokens nach dieser Regel eine j\u00e4hrliche Erneuerung?<\/h3>\n
F\u00fcr vor dem 30. Juli 2026 ausgestellte Tokens gilt nach der verlinkten Ads-Regel keine feste j\u00e4hrliche Frist. Widerruf und andere Ung\u00fcltigkeitsgr\u00fcnde ben\u00f6tigen weiterhin \u00dcberwachung. Ein neu ausgestelltes Ersatz-Token ist anhand aktueller Ausstellungs- und Einwilligungsbelege einzuordnen; der gew\u00f6hnliche Access-Token-Refresh ist keine neue Einwilligung.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n