Meta Marketing API v26.0: Die Änderungen vom 27.10.2026 und ein Prüfskript für bestehende Integrationen

Meta hat die Graph API v26.0 am 29.07.2026 ausgeliefert. Wer Ad-Automatisierung betreibt, greift jetzt reflexhaft zu dem Vorgehen, das seit Jahren trägt: Changelog lesen, die Integration auf der Version pinnen, die heute läuft, und die Migration auf eine ruhige Woche im Frühjahr legen. Dieser Reflex versagt diesmal. Am 27.10.2026 werden die zentralen v26.0-Änderungen in jeder noch unterstützten Version wirksam. Der Pin kauft nach diesem Datum nichts mehr. Es bleiben etwa elf Wochen, und die Arbeit ist ein Inventarproblem, kein Programmierproblem.

1. Warum der Version-Pin am 27.10.2026 aufhört zu wirken

Der übliche Vertrag mit einer versionierten API ist einfach. Eine neue Version bringt Breaking Changes, die alte Version behält ihr Verhalten bis zum End of Life, und der Wechsel geschieht nach eigenem Zeitplan. Genau dafür gibt es die Versionsnummer.

Der 27. Oktober bricht diesen Vertrag mit Absicht. Die zentralen v26.0-Änderungen gelten für alle Versionen, die an diesem Tag noch unterstützt werden, nicht nur für Aufrufe, die v26.0 im Pfad tragen. Der Satz, der im nächsten Planungsmeeting fällt und in der Hälfte aller Beiträge zu diesem Release steht, ist deshalb falsch: Eine ältere Version ist keine Absicherung. Es gibt keine Version, auf der sich sitzen bleiben ließe und die die entfernten Placements und Felder am Leben hält. Das Datum ist eine Plattformänderung mit Frist, und die Versionsnummer ist für die Betroffenheit irrelevant.

2. Was laut bricht, und was leise

Sechs Änderungen zählen, hier sortiert danach, wie laut sie sich melden.

• Instagram Explore Feed placement: entfernt, und Requests, die es weiterhin referenzieren, laufen in einen harten Fehler. Das zeigt sich innerhalb von Minuten.
• Drei delivery estimate fields: entfernt. Die exakten Feldnamen stammen aus dem Changelog und aus keiner anderen Quelle, auch nicht aus diesem Artikel; abzugleichen sind sie gegen die Feldlisten, die der eigene Code tatsächlich anfordert.
• Web-only destination: fällt weg. Jedes Ad Set, das darauf aufgebaut ist, braucht eine neue Entscheidung über das Ziel, keine Konfigurationskosmetik.
• Poll creatives: blockiert. Die Creative-Erstellung schlägt fehl.
• Special Ad Category: Ad Sets in den Kategorien Housing, Employment und Financial müssen sie ab jetzt explizit setzen. Implizit oder vererbt genügt nicht mehr.
• Messenger Stories: verschwinden still aus messenger_positions. Kein Fehler, keine Warnung, kein veränderter Statuscode.

Der letzte Punkt ist der teure. Das Alerting hängt mit ziemlicher Sicherheit an Fehlerraten und fehlgeschlagenen Jobs, und die Fehlerrate dieser Änderung bleibt bei null. Die Ad Sets melden weiterhin Erfolg, der Delivery-Mix verschiebt sich, und das erste Signal kommt Wochen später als unerklärlicher Knick in einer Performance-Kurve. Alles, was hart fehlschlägt, kostet einen Dienstagvormittag. Ein still entferntes Placement kostet ein Quartal mit trüber Attribution.

3. Die eigene Konfiguration prüfen, nicht die API

Der Einstieg führt nicht über Aufrufe gegen die API, sondern über die ohnehin gespeicherte Konfiguration, denn dort liegen die kritischen Strings: exportierte Ad-Set-Definitionen, die Templates, die der Kampagnengenerator rendert, die Feldlisten im Reporting-Extraktor. Die Herstellerfakten gehören in eine einzige, von Hand gepflegte watchlist.json, einmal aus dem Changelog übernommen, damit im Skript nichts geraten ist. Alles Übrige stammt aus den eigenen Daten.

#!/usr/bin/env python3
# audit_v26.py - prüft IHRE gespeicherte Ad-Set-Konfiguration auf v26.0-Betroffenheit.
import json, pathlib, sys

WATCH = json.loads(pathlib.Path("watchlist.json").read_text())
CONFIG_DIR = pathlib.Path("/srv/adops/adset_configs")
REGULATED = {"housing", "employment", "financial"}

def flatten(node, path=""):
    if isinstance(node, dict):
        for k, v in node.items():
            yield from flatten(v, f"{path}.{k}" if path else k)
    elif isinstance(node, list):
        for i, v in enumerate(node):
            yield from flatten(v, f"{path}[{i}]")
    else:
        yield path, node

findings = []
for f in sorted(CONFIG_DIR.glob("*.json")):
    doc = json.loads(f.read_text())
    flat = dict(flatten(doc))
    for path, value in flat.items():
        if value in WATCH["hard_fail_placements"]:
            findings.append((f.name, "HARD_FAIL", path, value))
        elif "messenger_positions" in path and value in WATCH["silent_drops"]:
            findings.append((f.name, "SILENT", path, value))
        elif value in WATCH["blocked_creatives"]:
            findings.append((f.name, "BLOCKED", path, value))
    for field in WATCH["removed_fields"]:
        hits = [p for p in flat if p.endswith(field)]
        if hits:
            findings.append((f.name, "REMOVED_FIELD", hits[0], field))
    if doc.get("vertical") in REGULATED and not doc.get("special_ad_category"):
        findings.append((f.name, "MISSING_SAC", "special_ad_category", doc["vertical"]))

for row in findings:
    print("\t".join(str(c) for c in row))
sys.exit(1 if any(r[1] == "HARD_FAIL" for r in findings) else 0)

Das Skript läuft bis zum Stichtag wöchentlich; derselbe Exit-Code gehört in den Job, der die Kampagnen-Templates ausrollt. Ein HARD_FAIL-Fund nach dem 27.10.2026 ist ein kaputtes Deployment. Besser scheitert jetzt der Build als später die Kampagne.

# /etc/cron.d/meta-v26-audit
MAILTO=adops@example.com
15 6 * * 1 adops cd /srv/adops && python3 audit_v26.py > /var/log/adops/v26-$(date +\%F).tsv 2>&1 || echo "v26 audit found blockers"

4. Die Checkliste je Endpoint, und der Comscore-Umstieg, den niemand eingeplant hat

1. Ad set create und update: Das Explore Feed placement entfernen, messenger_positions explizit setzen, statt sich auf Defaults zu verlassen, und die Special Ad Category für jedes Ad Set in Housing, Employment und Financial setzen.
2. Creative create: Poll creatives in der eigenen Validierungsschicht zurückweisen und jedes Ad Set neu planen, das die web-only destination genutzt hat.
3. Delivery estimate reads: Die drei Felder aus der Feldliste des Requests streichen und danach flussabwärts durch die Staging-Tabellen, Transformationsmodelle und Dashboard-Spalten verfolgen. Die API liefert sie nicht mehr; das Schema behält eine nullable Spalte klaglos für immer.
4. Reporting: Die Geo-Dimension erneut prüfen, siehe unten.
5. Verifikation: Den gesamten Pfad gegen ein eigenes Test-Werbekonto mit kleinem Budget durchspielen, einmal vor dem 27.10.2026 und einmal am Morgen danach.

Der Reporting-Punkt hängt nicht am Oktober-Datum, er ist bereits scharf. Am 22.06.2026 hat Meta die geografische Auflösung im Reporting von DMA auf Comscore Markets umgestellt. Wo ein Warehouse Meta-Geo-Zeilen gegen eine DMA-Dimensionstabelle joint, verliert dieser Join seit sieben Wochen stillschweigend Zeilen, und jedes Dashboard, das diesen Sommer mit dem letzten vergleicht, vergleicht zwei verschiedene Geografien. Zuerst gehört der Schaden ermittelt, danach fällt die Entscheidung über das neue Mapping.

-- Zeilen, die sich nicht mehr gegen die alte DMA-Dimension auflösen lassen.
SELECT f.report_date, f.geo_name, SUM(f.impressions) AS impressions
FROM meta_geo_daily f
LEFT JOIN dim_dma d ON d.dma_name = f.geo_name
WHERE f.report_date >= DATE '2026-06-01'
  AND d.dma_code IS NULL
GROUP BY 1, 2
ORDER BY impressions DESC
LIMIT 25;

5. Fazit

Damit stehen zwei kleine Dinge: ein Audit-Skript, das die eigene gespeicherte Ad-Set-Konfiguration gegen eine von Hand kopierte Watchlist liest und bei allem, was hart fehlschlagen wird, mit einem Exit-Code ungleich null endet, und eine Checkliste, die jede v26.0-Änderung dem Endpoint und der nachgelagerten Tabelle zuordnet, die sie berührt. Keines von beidem hängt an geratenen API-Antworten.

Der Gewinn ist der Unterschied zwischen es am 27.10.2026 zu erfahren und es heute zu wissen. Die lauten Änderungen wären ohnehin aufgefallen. Der Wert liegt in den beiden, die das nicht tun: Messenger Stories, die ohne Fehler aus messenger_positions verschwinden, und der Wechsel von DMA auf Comscore, der das Geo-Reporting seit Juni verzerrt. Dazu kommt die eine Korrektur, die in jede Quartalsplanung gehört: Das Pinnen auf eine ältere Version ist hier keine Absicherung. Jeder Feldname und jeder Placement-String gehört gegen die Primärquelle geprüft, bevor sich eine Zeile ändert: Graph API Changelog, version 26.0.