Meta Marketing API v26.0: Der 27.10.2026 hebelt Ihren Version-Pin aus
Inhalt
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 Ihnen nach diesem Datum nichts mehr. Sie haben 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 Sie entscheiden, wann Sie wechseln. 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, den Sie im nächsten Planungsmeeting hören und in der Hälfte aller Beiträge zu diesem Release lesen werden, ist deshalb falsch: Nein, Sie sind nicht sicher, nur weil Sie noch auf einer älteren Version stehen. Es gibt keine Version, auf der Sie sitzen bleiben können und die die entfernten Placements und Felder am Leben hält. Behandeln Sie das Datum als Plattformänderung mit Frist, und behandeln Sie die Versionsnummer als irrelevant für Ihre Betroffenheit.
2. Was laut bricht, und was leise
Sechs Änderungen zählen. Sortieren Sie sie danach, wie sie bei Ihnen ankommen.
- Instagram Explore Feed placement: entfernt, und Requests, die es weiterhin referenzieren, laufen in einen harten Fehler. Das merken Sie innerhalb von Minuten.
- Drei delivery estimate fields: entfernt. Nehmen Sie die exakten Feldnamen aus dem Changelog und aus keiner anderen Quelle, auch nicht aus diesem Artikel, und gleichen Sie sie gegen die Feldlisten ab, die Ihr 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. Ihr Alerting hängt mit ziemlicher Sicherheit an Fehlerraten und fehlgeschlagenen Jobs, und die Fehlerrate dieser Änderung bleibt bei null. Ihre Ad Sets melden weiterhin Erfolg, Ihr Delivery-Mix verschiebt sich, und das erste Signal erreicht Sie 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. Prüfen Sie Ihre eigene Konfiguration, nicht die API
Beginnen Sie nicht mit Aufrufen gegen die API. Beginnen Sie mit der Konfiguration, die Sie ohnehin speichern, denn dort liegen die kritischen Strings: exportierte Ad-Set-Definitionen, die Templates, die Ihr Kampagnengenerator rendert, die Feldlisten in Ihrem Reporting-Extraktor. Halten Sie die Herstellerfakten in einer einzigen, von Hand gepflegten watchlist.json, einmal aus dem Changelog übernommen, damit im Skript nichts geraten ist. Alles Übrige gehört Ihnen.
#!/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)Lassen Sie es bis zum Stichtag wöchentlich laufen, und verdrahten Sie denselben Exit-Code in den Job, der Ihre Kampagnen-Templates ausrollt. Ein HARD_FAIL-Fund nach dem 27.10.2026 ist ein kaputtes Deployment. Lassen Sie also lieber jetzt den Build scheitern 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
- Ad set create und update: Entfernen Sie das Explore Feed placement, setzen Sie
messenger_positionsexplizit, statt sich auf Defaults zu verlassen, und setzen Sie die Special Ad Category für jedes Ad Set in Housing, Employment und Financial. - Creative create: Weisen Sie poll creatives in Ihrer eigenen Validierungsschicht zurück, und planen Sie jedes Ad Set neu, das die web-only destination genutzt hat.
- Delivery estimate reads: Streichen Sie die drei Felder aus der Feldliste des Requests, und verfolgen Sie sie danach flussabwärts durch Ihre Staging-Tabellen, Transformationsmodelle und Dashboard-Spalten. Die API liefert sie nicht mehr; Ihr Schema behält eine nullable Spalte klaglos für immer.
- Reporting: Prüfen Sie die Geo-Dimension erneut, siehe unten.
- Verifikation: Spielen Sie den gesamten Pfad gegen ein Test-Werbekonto mit kleinem Budget durch, das Sie selbst kontrollieren, 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. Wenn Ihr 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. Ermitteln Sie zuerst den Schaden, entscheiden Sie danach ü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
Sie haben zwei kleine Dinge gebaut: ein Audit-Skript, das Ihre 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.
Was Ihnen das einbringt, ist der Unterschied zwischen es am 27.10.2026 zu erfahren und es heute zu wissen. Die lauten Änderungen hätten Sie ohnehin eingeholt. 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 Ihr Geo-Reporting seit Juni verzerrt. Und es bringt Ihnen die eine Korrektur, die man jeder Quartalsplanung wiederholen sollte: Das Pinnen auf eine ältere Version ist hier keine Absicherung. Prüfen Sie jeden Feldnamen und jeden Placement-String gegen die Primärquelle, bevor Sie eine Zeile ändern: Graph API Changelog, version 26.0.
Passend dazu
