Notion Dev Day 2026 markiert den Moment, in dem Notion aufgehört hat, nur ein Produktivitäts-Tool zu sein, und zu einer echten Entwicklerplattform geworden ist — mit Workers, einem Agent SDK und einer Agent API, die deinen Workspace gemeinsam zu einem programmierbaren System of Record machen.
Wenn du die Ankündigungen verfolgt hast und dachtest: “Das klingt sehr technisch” — keine Sorge. Du musst keine einzige Zeile Code schreiben, um von dem zu profitieren, was hier gerade passiert ist. Und wenn du Code schreibst (oder KI für dich schreiben lässt), ist die Decke gerade deutlich höher geworden.
Hier ist alles, was angekündigt wurde, was es für deinen Workspace bedeutet und wie du heute damit anfangen kannst. Für spezifische Notion AI-Terminologie sieh dir das Notion AI Dictionary an.
Was sind Notion Workers und warum sollte dich das interessieren?
Notion Workers sind kleine Codestücke, die direkt auf Notions Servern laufen und das erweitern, was dein Workspace leisten kann — weit über die eingebauten Features hinaus.
Stell dir einen Worker wie ein Spezialwerkzeug vor, das du deinem Notion-Setup gibst. Wenn du schon mal Notions eingebaute Automationen genutzt hast — das kleine ⚡-Symbol in deinen Datenbanken — dann sind Workers im Grunde genau das, aber auf Steroiden. Sie können alles, was eine normale Automation nicht kann: über Datenbanken hinweg suchen, externe APIs ansprechen, komplexe Logik ausführen und vieles mehr.
Ja, Workers brauchen Code. Aber 2026 ist das kaum noch eine Hürde. Tools wie Claude Code und Codex können einen funktionierenden Worker aus einer einfachen Beschreibung generieren. Wir veröffentlichen diese Woche noch ein vollständiges Tutorial — auch ohne Terminalerfahrung kannst du es problemlos nachvollziehen.
Wie erscheinen Workers in deinem Workspace?
Workers können auf drei verschiedene Arten ausgelöst werden, jede für andere Use Cases geeignet.
1. Als Tool für Custom Agents
Du kannst einen Worker als Tool an jeden Notion Custom Agent anhängen — wie deinem Agenten einen neuen Trick beibringen. Custom Agents können von Haus aus nicht mit jedem externen Service kommunizieren. Zum Beispiel gibt es keinen eingebauten Connector für ConvertKit (Kit), die Newsletter-Plattform, die wir nutzen.
Also haben wir einen kleinen Worker gebaut, der auf Kits API zugreift, und ihn unserem Agenten als Tool gegeben. Jetzt kann der Agent automatisch Newsletter-Daten während seiner Runs abrufen. Eine Fähigkeit, die Notion AI nativ einfach nicht hat — und die ein Worker in wenigen Minuten nachrüstet.
2. Via Webhook-Trigger
Das ist neu seit Dev Day. Workers können jetzt durch Webhooks ausgelöst werden, was bedeutet: Sie laufen ohne jegliche KI-Beteiligung. Etwas passiert in deinem Workspace → der Worker wird ausgelöst → der Job erledigt sich. Reine Automation, keine Tokens verbrannt.
Das Besondere daran: Notion hat Webhooks direkt in seine Datenbank-Automationen eingebaut. Du kannst also eine vollständige Kette innerhalb von Notion aufbauen — Datenbank-Automation schickt einen Webhook, Webhook triggert einen Worker, Worker erledigt die schwere Arbeit. Ein kompletter Automations-Loop, ohne die Plattform zu verlassen.
3. Nach einem Sync-Schedule
Sync Workers laufen nach einem Zeitplan — alle 15 Minuten, jede Stunde, einmal täglich — und ziehen externe Daten in Notion. Wir gehen weiter unten genauer auf Sync ein, weil es einige besondere Eigenschaften hat, die es besonders interessant machen. Wenn du mit externen APIs baust, findest du im Notion API Guide Infos zu Preisen, Token-Verbrauch und Best Practices.
Sechs praktische Beispiele für Notion Workers
Lass uns konkret werden. Hier sind sechs reale Use Cases, in denen Workers glänzen.
🏢 Company Enricher
Wenn du ein neues Unternehmen in deinem CRM anlegst und die Domain einträgst, holt ein Worker automatisch das Firmenlogo und setzt es als Seiten-Icon. Optional kann er auch die Unternehmenswebsite scrapen (über einen Service wie Firecrawl) und Properties wie Branche, Größe und aktuelle News automatisch befüllen.
Kleine visuelle Verbesserung, großer Unterschied in der Usability — und das skaliert auf Hunderte von Einträgen, ohne dass du einen Finger rührst.
✅ Task Generator
Einer der häufigsten Automation-Flows, den wir früher mit Make oder N8N gebaut haben. Das Szenario: Bestimmte Projekttypen brauchen immer dieselbe Aufgabenliste. Ein Marketing-Kampagnenprojekt hat immer diese sieben Schritte, ein Onboarding immer diese zwölf.
Das Optimum ist eine separate Prozess-Datenbank, in der du definierst, welche Aufgaben zu welchem Projekttyp gehören. Ein Worker beobachtet neue Projekte, sucht den passenden Prozess und erstellt alle Aufgaben automatisch. Früher brauchte das ein externes Tool. Jetzt läuft es nativ in Notion.
🔍 Duplicate Checker
Duplikate in Notion zu finden ist kein Vergnügen — es gibt keine eingebaute Funktion dafür. Du könntest KI nutzen, aber das verbraucht schnell Tokens. In Code hingegen ist Duplikat-Erkennung ein gelöstes Problem. Ein Worker kann jeden neuen Eintrag sofort mit bestehenden Datensätzen abgleichen und Duplikate kennzeichnen oder zusammenführen.
⏰ Overdue Escalator
Ein geplanter Worker, der in regelmäßigen Abständen Fälligkeitsdaten prüft, überfällige Aufgaben identifiziert, sie den verantwortlichen Team-Leads zuordnet und Benachrichtigungen verschickt. Denk an einen proaktiven Projektgesundheits-Monitor, der im Hintergrund läuft.
💳 External Status Sync
Workers können auf externe APIs zugreifen. Den Zahlungsstatus von Rechnungen aus Stripe abrufen, Bestellupdates aus Shopify holen oder Ticket-Status aus Zendesk synchronisieren — alles automatisch in deinen Notion-Datenbanken gespiegelt.
📝 Smarter Meeting Notes Sync
Wenn du ein externes Meeting-Tool nutzt, kennst du den Schmerz: Du bereitest eine Agenda in Notion vor, aber wenn die Notizen hinterher eintreffen, erstellen sie einen neuen Eintrag statt sich mit dem bestehenden zu verbinden.
Ein Worker kombiniert mit einem Agenten löst das elegant. Der Code übernimmt das offensichtliche Matching (identische Titel, passende Startzeiten). Bei unklaren Fällen wendet die KI kontextuelles Urteilsvermögen an. Und weil 80 % der Arbeit im Code passiert — der praktisch kostenlos läuft — sinken deine Gesamtkosten für den Agenten drastisch gegenüber einem rein KI-getriebenen Ansatz.
Pro-Tipp: Dieses letzte Beispiel zeigt ein wichtiges Design-Prinzip für Workers. Nutze Code für die deterministischen, repetitiven Teile und reserviere KI für die Urteilsentscheidungen. Mit diesem Ansatz kannst du deinen Token-Verbrauch bei gemischten Workflows um 80 % oder mehr reduzieren. Strategien zur Kostenoptimierung findest du im Artikel how to reduce Notion agent costs.
Was kosten Workers?
Workers nutzen dasselbe Credit-System wie Notion Agents — aber zu einem Bruchteil der Kosten.
KI-Reasoning ist teuer — es braucht enormen Rechenaufwand, damit Modelle Probleme durchdenken können. Code-Ausführung ist dagegen spottbillig. Workers sind zwar ein kostenpflichtiges Add-on, aber die Preisgestaltung spiegelt diesen Unterschied wider.
Notion hat einige Beispielrechnungen geteilt:
- Salesforce-Tickets alle 15 Minuten abfragen → 86 Cent pro Monat
- Einmal täglich aus Jira ziehen → 1 Cent pro Monat
- Intensive Nutzung (9.800 Runs/Monat für Help-Desk-Tickets) → ca. 13 $ pro Monat
Dazu kommt: Workers sind bis zum 11. August 2026 komplett kostenlos. Das gibt dir fast drei Monate zum Bauen, Testen und Optimieren, bevor irgendetwas berechnet wird.
Um Workers zu aktivieren, musst du Workspace-Owner auf dem Business-Plan oder höher sein. Geh zu Einstellungen → Features → Workers und klick auf den Aktivierungsbutton. Für professionelle Implementierungsunterstützung können Notion Consulting Services dir helfen, deine Worker-Infrastruktur aufzusetzen.
Wie funktioniert Notion Sync?
Sync ist ein spezieller Worker-Typ, der für einseitige Daten-Imports in Notion entwickelt wurde — mit eingebautem Schutz vor versehentlichem Überschreiben.
Wenn du ein externes System hast, das die Single Source of Truth ist — Salesforce für deine Deals, ein HRIS für Mitarbeiterdaten, ein Ticketing-System für Support-Anfragen — und du diese Daten in Notion sehen möchtest, ohne zu riskieren, dass jemand synchronisierte Werte versehentlich ändert, dann ist Sync deine Antwort.
Was macht Sync anders als einen normalen Worker?
Sync Workers erstellen und verwalten ihre eigene dedizierte Datenbank. Das ist eine bewusste Design-Entscheidung.
Wenn du einen Sync einrichtest, deklarierst du, welche Properties aus der externen Quelle gezogen werden — Name, Status, Wert, was auch immer du brauchst. Diese synchronisierten Properties sind gesperrt. Du kannst sie sehen und Werte kopieren, aber du kannst sie nicht im Notion UI bearbeiten. Die Daten fließen in eine Richtung: von der externen Quelle in Notion.
Aber hier wird es clever: Du kannst eigene Notion-native Properties obendrauf legen. Einen internen Owner zuweisen, den Datensatz mit anderen Notion-Datenbanken verlinken, Tags oder Notizen hinzufügen — alles unter deiner vollen Kontrolle. Die synchronisierten Daten bleiben sauber und geschützt; deine interne Anreicherungsschicht liegt daneben.
Das löst ein Problem, das wir in der Kundenarbeit ständig sehen: Jemand ändert einen synchronisierten Property-Wert in Notion, der nächste Sync überschreibt ihn, und die Verwirrung ist groß. Mit Syncs Architektur ist das schlicht unmöglich.
Wann solltest du Sync vs. einen normalen Worker verwenden?
Nutze Sync wenn:
- Das externe System die Single Source of Truth ist
- Du nur Daten in Notion einlesen musst (einseitig)
- Du gesperrte Properties willst, die nicht versehentlich geändert werden können
- Du mit einer neuen, dedizierten Datenbank für die synchronisierten Daten einverstanden bist
Nutze einen normalen Worker wenn:
- Du bidirektionale Synchronisation brauchst (lesen und zurückschreiben)
- Du Daten in eine bestehende Notion-Datenbank pushen willst
- Du komplexere Logik brauchst, die über simples Daten-Mirroring hinausgeht
Pro-Tipp: In Sync-Datenbanken kannst du Properties umbenennen, ohne den Sync zu unterbrechen — eine interne ID hält die Verbindung aufrecht. Den Property-Typ kannst du allerdings nicht ändern. Wenn der Sync ein Textfeld deklariert hat, bleibt es ein Textfeld.
Was ist das Notion Agent SDK?
Das Agent SDK lässt externe Tools mit deinen Notion Agents sprechen — du kannst also endlich mit Notion AI interagieren, ohne in Notion zu sein.
Das ist ein bedeutender Wandel. Bisher bedeutete Notion AI nutzen: Notion öffnen. Die einzige Ausnahme war die Slack-Integration für Custom Agents. Das SDK reißt diese Tür weit auf — und es funktioniert für beide: Custom Agents und deinen Personal Agent.
Das SDK ist derzeit in der Alpha-Phase mit Zugang per Warteliste. Du kannst dich im offiziellen GitHub-Repository anmelden.
Warum ist das für deinen Workflow relevant?
Stell dir vor, du bist tief in Claude Code und baust eine Marketing-Kampagne. Du brauchst die neuesten Details aus drei Kunden-Meetings, die in Notion liegen. Früher würdest du den Kontext wechseln: Notion öffnen, nach den Meetings suchen, die relevanten Teile kopieren, zurück einfügen.
Mit dem SDK kann Claude Code deinen Notion-Agenten direkt anpingen. Der Agent durchsucht deinen Workspace, holt die Meeting-Details und schickt sie zurück — alles ohne Notion zu öffnen.
Oder umgekehrt: Du hast gerade einen Entwicklungs-Sprint in Codex abgeschlossen und möchtest die Ergebnisse in dein Projektmanagement-System in Notion zurückschreiben. Codex könnte das über die API tun, klar. Aber ein Notion-Agent, der mit der Struktur deines Workspace, den Namenskonventionen und verknüpften Datenbanken vertraut ist, erledigt das zuverlässiger. Der Agent kennt dein System. Das ist seine Zone of Genius.
Das “Zone of Genius”-Prinzip
Das ist die zentrale Erkenntnis hinter dem SDK. Jedes Tool hat seinen Sweet Spot:
- Notion AI glänzt bei allem, wo Inputs und Outputs in Notion leben — suchen, erstellen, verlinken, Workspace-Inhalte aktualisieren
- Claude Code / Codex glänzt beim Code schreiben, mit Dateien arbeiten, Assets generieren
- Spezialisierte Agenten (Research, Datenanalyse usw.) haben jeweils ihre eigenen Stärken
Das SDK lässt dich jede Aufgabe zum Tool routen, das dafür am besten geeignet ist — ohne dass der Mensch manuell Informationen zwischen ihnen pendeln muss.
In unserer eigenen Arbeit haben wir dieses Muster schon mit Tools wie OpenClaw gesehen. Das SDK macht es nativ — kein Middleware-Layer mehr nötig.
Zurück zum Multiplayer
Es gibt einen größeren Trend, den es zu beachten gilt. Gerade passiert noch viel KI-Arbeit im Einzelspieler-Modus. Menschen flüchten zu Claude Code oder Codex, bauen Dinge in ihrer lokalen Umgebung — und der Output bleibt isoliert.
Das ist das Gegenteil von Zusammenarbeit. Wenn du Work Output erstellst, der in einem zentralen System leben sollte — und Notion ist dieses System — brauchst du eine Brücke zurück.
Das SDK ist diese Brücke. Es macht es einfach, Informationen zurück an die richtige Stelle in deinem Workspace fließen zu lassen, auch wenn die Arbeit woanders stattgefunden hat.
Was ist die Notion Agent API?
Die Agent API ist das Gegenstück zum SDK. Während das SDK es externen Tools ermöglicht, mit Notion Agents zu sprechen, lässt die API externe Agenten als vollwertige Mitglieder in Notion einziehen.
Deine Claude-Agenten, Codex-Agenten und alle anderen externen KI-Agenten erscheinen direkt in deinem Notion-Agenten-Menü. Du kannst mit ihnen interagieren, ihnen Aufgaben zuweisen und ihre Workflows verwalten — alles von innerhalb Notion.
Die Agent API befindet sich derzeit in der Beta-Phase mit Zugang per Warteliste.
Wie ändert das den Arbeitsalltag?
Stell dir ein gemeinsames Task Board in Notion vor, auf dem dein gesamtes Team — Menschen und KI-Agenten — zusammenarbeitet.
Ein neues Engineering-Ticket kommt rein. Du weist es deinem Claude Code Agent zu, der mit der Implementierung beginnt. Ein Content Brief trifft ein — du leitest ihn an einen spezialisierten Writing Agent weiter. Eine Datenanalyse-Anfrage? Die geht an deinen Analytics Agent.
Jeder Agent wählt das richtige Tool für den Job. Notion AI übernimmt alles, wo Inputs und Outputs in deinem Workspace leben. Claude übernimmt den Code. Spezialisierte Agenten ihre jeweiligen Domänen. Und du orchestrierst das alles von einer zentralen Oberfläche.
Wenn Agenten ihre Arbeit abgeschlossen haben, aktualisieren sie den Task-Status, schreiben ihren Output zurück auf das gemeinsame Board und bewegen das Element in der Pipeline vorwärts. Kein Copy-Pasting zwischen Tools. Kein verlorener Kontext.
Die Orchestrierungsschicht, für die Notion gebaut wurde
Das ist wohl die strategisch wichtigste Ankündigung des Dev Days. Notion hat immer nach dem Hub-and-Spoke-Modell funktioniert — dein zentrales System, verbunden mit spezialisierten Tools drumherum. Mit wachsenden Unternehmen war Notion nie als All-in-One-Tool für alles gedacht.
Die Agent API erweitert dieses Modell auf KI. Dein Workspace wird zur Orchestrierungsschicht, in der alle Agenten — intern und extern — zusammenkommen.
Wer arbeitet woran? Was ist die nächste Aufgabe? Was ist unsere allgemeine Dokumentation? Das sind dieselben menschlichen Kollaborationsprobleme, die Notion bereits gut löst. Jetzt profitieren alle deine KI-Agenten von derselben Koordinationsinfrastruktur.
Wie richtest du das alles ein?
Alles läuft über die Notion CLI (Command-Line Interface), erreichbar über den ntn-Befehl in deinem Terminal.
Die CLI lässt dich:
- Dich einloggen und deinen Notion Workspace autorisieren
- Workers deployen
- Worker-Status und Logs einsehen
- Sync-Schedules konfigurieren
- Den gesamten Worker-Lifecycle verwalten
Wenn du noch nie mit einem Terminal gearbeitet hast — kein Problem. Wir veröffentlichen diese Woche noch ein vollständiges Schritt-für-Schritt-Tutorial, das alles durchgeht — auch als nicht-technische Person. Mit Claude Code oder Codex, der den eigentlichen Code generiert, geht es bei der CLI hauptsächlich ums Deployen und Verwalten.
Das offizielle Workers-Template-Repository findest du unter github.com/makenotion/workers-template. Für das Agent SDK geht’s zu github.com/makenotion/notion-agents-sdk-js.
Wichtig: Du kannst einen Worker nicht ohne die CLI deployen. Es gibt keinen reinen UI-Weg dafür. Aber nochmal — das Setup ist unkompliziert, sobald du ein paar grundlegende Konzepte verstanden hast.
Was bedeutet das für Notion als Plattform?
Notion wird zu einem echten System of Record — einem zentralen Hub, der sich mit jedem KI-Setup verbinden lässt, das du darauf aufbauen möchtest. Für einen tieferen Einblick, wie diese Orchestrierung intern funktioniert, sieh dir an, how Notion uses AI agents.
| Feature | Was es tut | Verfügbar | Am besten für |
|---|---|---|---|
| Workers (Tool) | Custom Code als Agent-Tools | ✅ Heute | Agent-Fähigkeiten erweitern |
| Workers (Webhook) | Code, ausgelöst durch Events | ✅ Heute | KI-freie Automationen |
| Workers (Sync) | Geplanter einseitiger Datenabruf | ✅ Heute | Externe Daten spiegeln |
| Agent SDK | Externe Tools sprechen mit Notion AI | 🔜 Alpha (Warteliste) | Notion AI aus Claude, Codex usw. nutzen |
| Agent API | Externe Agenten in Notion | 🔜 Beta (Warteliste) | Alle Agenten von einem Hub aus orchestrieren |
| CLI (ntn) | Alles deployen und verwalten | ✅ Heute | Worker-Deployment und Lifecycle |
Diese Tabelle ist die Kurzübersicht. Aber das größere Bild ist das, was wirklich zählt.
Wir alle wissen inzwischen: Kontext ist die wichtigste Zutat für effektive KI. Das Wissen deines Unternehmens, deine Prozesse, Beziehungen und Geschichte — das macht KI nützlich, nicht das Modell selbst.
Notion positioniert sich als dein Kontext in einer Box. Ein zentrales Repository, auf das jeder Agent — intern oder extern — zugreifen kann. Ob Notions eigene Custom Agents das beste Tool für einen bestimmten Job sind, oder ob Claude, Codex oder ein spezialisierter Drittanbieter-Agent besser geeignet ist, spielt keine Rolle mehr. Sie können alle auf denselben Kontext zugreifen und im selben Raum zusammenarbeiten.
Der Übergang von No-Code zu Code
Es gibt einen Meta-Trend, den es anzuerkennen gilt. Workers und No-Code-Tools (Make, N8N, Zapier) lösen im Kern dasselbe Problem: Notion über seine eingebauten Möglichkeiten hinaus zu erweitern.
Im Venn-Diagramm überlappen sie sich fast zu 100 %. Beide ermöglichen dir, Automationen zu bauen, externe Services zu verbinden und Custom-Logik zu erstellen.
Aber Workers haben strukturelle Vorteile, die sich mit der Zeit verstärken:
- Kein zusätzliches Tool zu pflegen, zu bezahlen oder zu genehmigen — Workers laufen innerhalb von Notion
- Code wird jeden Monat einfacher zu schreiben — KI-gestütztes Coding bedeutet, in einfacher Sprache zu beschreiben, was man möchte
- Direkte Integration mit Custom Agents — Workers können Tools sein, die Agenten nutzen, was mit No-Code deutlich schwieriger ist
- Kosteneffizienz — keine Middleware-Abonnementgebühren
Intern haben wir bereits aufgehört, No-Code-Automationen für unsere eigenen Workflows zu bauen. Wir deployen sie noch in bestimmten Kundensituationen, wo Workers Einschränkungen haben (Laufzeit-Limits, begrenzte Handles zwischen Workers), aber die generelle Richtung ist klar.
Werden wir in sechs Monaten noch mit Make oder N8N bauen? Ehrlich gesagt — für die meisten Use Cases wahrscheinlich nicht.
Pro-Tipp: Reiß deine bestehenden No-Code-Automationen nicht morgen raus. Aber für jede neue Automation, die du baust, überlege, ob ein Worker das erledigen könnte. Fang mit etwas Einfachem an — einem Company Enricher oder einem Webhook-getriggerten Status-Updater — und baue von dort aus Selbstvertrauen auf. Du willst tiefer einsteigen? Schau dir unseren Custom Agents Complete Guide an und abonniere Notion for Teams für wöchentliche Frameworks zum Workspace-Aufbau.
Notion übergibt dir die Schlüssel
Wenn du die Entwicklung des Notion-Ökosystems verfolgt hast, erkennst du ein Muster. Die Anfangstage waren geprägt von kreativen Workarounds — Features zusammenkleben, um Dinge zu tun, für die das Tool nicht gedacht war. Mit mehr nativen Features von Notion wurden die Workarounds weniger nötig.
Jetzt hebt sich die Decke wieder. Die Möglichkeit, Code innerhalb von Notion auszuführen, Notion Agents von überall aus aufzurufen und externe Agenten in deinen Workspace zu bringen — das öffnet Möglichkeiten, die wir uns noch gar nicht vorstellen können. Melde dich für unseren Newsletter an für Updates, während sich dieses Ökosystem weiterentwickelt.
Notion übergibt Nutzern die Schlüssel zum Maschinenraum. Was du damit baust, liegt bei dir.
Häufig gestellte Fragen
Muss ich Code schreiben können, um Workers zu nutzen?
Nicht wirklich. Workers werden zwar in TypeScript geschrieben, aber KI-Coding-Tools wie Claude Code und Codex können einen vollständig funktionsfähigen Worker aus einer einfachen Beschreibung generieren. Du musst die Notion CLI (ntn) nutzen, um sie zu deployen, aber der Prozess ist unkompliziert. Wir veröffentlichen diese Woche noch ein vollständiges Einsteiger-Tutorial, das jeden Schritt durchgeht.
Was kosten Workers nach dem kostenlosen Zeitraum?
Workers nutzen dasselbe Credit-System wie Notion Agents, aber zu einem Bruchteil des Preises. Code-Ausführung ist um Größenordnungen günstiger als KI-Reasoning. Notions Beispielrechnungen zeigen Kosten von 1 Cent pro Monat (täglicher Jira-Abruf) bis ca. 13 $ pro Monat bei intensiver Nutzung (9.800 Runs). Der kostenlose Zeitraum läuft bis zum 11. August 2026 — genug Zeit zum Bauen und Optimieren.
Was ist der Unterschied zwischen Agent SDK und Agent API?
Das SDK lässt externe Tools (Claude Code, Codex, OpenClaw) deine Notion Agents von außerhalb Notion aufrufen. Die API macht das Gegenteil — sie bringt externe Agenten als vollwertige Mitglieder in Notion. Kurz gesagt: SDK = outbound (Notion Agents antworten auf externe Anfragen), API = inbound (externe Agenten erscheinen in deinem Notion Workspace).
Kann ich Workers mit meinen bestehenden Datenbanken nutzen?
Ja, für normale Workers und Webhook-getriggerte Workers — sie können aus jeder Datenbank lesen und schreiben, zu der du ihnen Zugang gibst. Sync Workers sind die Ausnahme: Sie erstellen und verwalten ihre eigene dedizierte Datenbank mit gesperrten Properties. Wenn du externe Daten in eine bestehende Datenbank pushen möchtest, nutze lieber einen normalen Worker statt Sync.
Wann werden Agent SDK und Agent API allgemein verfügbar sein?
Beide stehen noch auf Wartelisten — das SDK in der Alpha- und die API in der Beta-Phase. Notion rollt den Zugang schrittweise aus. Du kannst dich über die Links in der offiziellen Dokumentation und dem Agent SDK GitHub-Repository anmelden. Workers, Webhooks und Sync sind heute für Workspaces im Business-Plan und darüber verfügbar.
Hier sind die Wartelisten-Links:
