Notion Developer Platform 3.5 : guide complet

Shubham SHARMA Mis à jour le 10 septembre 2026

La Notion Developer Platform 3.5, annoncée le 13 mai 2026, transforme Notion en hub d’orchestration d’agents IA. Pour la première fois, une équipe peut faire tourner du code personnalisé, intégrer Claude Code ou Codex comme agents natifs, et déclencher des workflows depuis n’importe quelle application — sans gérer la moindre infrastructure externe.

Depuis le lancement, plus d’un million d’agents personnalisés ont déjà été construits par des équipes dans le monde. Et la plateforme continue de mûrir vite : le 20 août 2026, les Agent APIs sont passées en bêta publique — vous pilotez désormais un Custom Agent entièrement par code (sessions, streaming, gestion des crédits), sans liste d’attente. La veille, le 19 août, Notion avait déjà rapatrié tout le portail développeur dans la sidebar de l’espace de travail et ajouté une barre développeur qui copie n’importe quel identifiant (page, base, bloc, workspace, utilisateur) en un clic. Attention : les équipes qui avaient bâti sur les routes alpha ont jusqu’au 30 septembre 2026 pour migrer. Je détaille tout cela plus bas.

Les 5 briques de la Developer Platform 3.5

Anatomie des 5 composants Notion Developer Platform 3.5 — CLI, Workers, External Agents API, Agent SDK, Webhooks entrants avec statut et plan requis 5 composants, désormais tous en bêta publique : depuis le 20 août 2026, les Agent APIs (External Agents et pilotage programmatique) ont quitté l’alpha privée et rejoignent le CLI, les Workers et les webhooks.

La plateforme se décompose en cinq composants distincts, chacun répondant à un besoin précis. Vous n’êtes pas obligé d’utiliser les cinq : certaines équipes démarreront avec le CLI et les webhooks, d’autres iront directement vers l’External Agents API.

Composant	Statut	Plan requis	Disponible maintenant
CLI `ntn`	Bêta publique	Tous plans	Oui
Workers	Bêta publique	Business / Enterprise	Oui (payant depuis le 11/08)
External Agents API	Bêta publique	Business / Enterprise	Oui (depuis le 20/08)
Agent SDK	Bêta publique	Business / Enterprise	Oui (depuis le 20/08)
Webhooks entrants	Bêta publique	Business / Enterprise	Oui

Depuis le passage des Agent APIs en bêta publique le 20 août 2026, les cinq composants sont accessibles sans liste d’attente. Le CLI et les webhooks restent les deux briques les plus simples pour débuter ; les External Agents, l’Agent SDK et le pilotage programmatique des agents s’obtiennent désormais directement via app.notion.com/developers.

Workers : exécuter du code dans le sandbox Notion

Les Notion Workers existent depuis plusieurs mois en alpha, mais la version 3.5 marque leur passage en bêta publique avec une architecture clarifiée. Un Worker est une fonction TypeScript qui tourne dans un environnement hébergé par Notion — pas de Lambda, pas de serveur, pas de cron externe à maintenir.

Ce que vous pouvez construire avec un Worker

Trois types de Workers couvrent la majorité des cas d’usage :

Database Sync — un Worker planifié qui tire des données depuis n’importe quelle API vers une base Notion. Synchroniser les tickets Zendesk, les contacts Salesforce, les transactions Stripe ou les données PostgreSQL devient une affaire de quelques dizaines de lignes de TypeScript.

Agent Tools — des fonctions déterministes que vos Custom Agents peuvent appeler. Contrairement aux appels LLM chaînés, ces outils s’exécutent de façon prévisible et consomment moins de tokens. Selon la documentation officielle, ils offrent « une fiabilité et un coût en tokens bien inférieurs à ceux du raisonnement LLM pour les actions répétitives ».

Webhook Triggers — des handlers qui reçoivent des événements HTTP entrants et déclenchent des workflows Notion en réponse (voir la section dédiée ci-dessous).

Déployer votre premier Worker

# Installer le CLI
curl -fsSL https://ntn.dev | bash

# S'authentifier
ntn login

# Créer un nouveau Worker
ntn workers new mon-premier-worker
cd mon-premier-worker

# Déployer
ntn workers deploy

Chaque Worker s’exécute dans un sandbox éphémère (infrastructure Vercel Sandbox, basée sur des microVMs Firecracker) avec son propre noyau et sa propre pile réseau. Les secrets (clés API, tokens) sont injectés via un proxy réseau sans jamais entrer dans l’environnement d’exécution.

Point important : la gratuité des Workers a pris fin le 11 août 2026. Depuis cette date, chaque exécution consomme des Notion Credits. Je recommande de journaliser vos invocations via les logs de déploiement (accessibles dans la section Développeur de la sidebar) pour maîtriser les coûts de production.

CLI `ntn` : piloter Notion depuis le terminal

Le CLI est le fil conducteur de toute la Developer Platform. Il s’installe en une ligne, fonctionne sur macOS et Linux (Windows via WSL), et est disponible sur tous les plans Notion, y compris le plan gratuit.

Ce que le CLI permet

Au-delà du déploiement de Workers, ntn ouvre un accès programmatique complet à votre workspace :

# Appel direct à l'API Notion
ntn api GET /v1/users/me

# Lister les webhooks actifs
ntn workers webhooks list

# Inspecter les exécutions
ntn workers runs list
ntn workers runs logs <run-id>

Le CLI supporte trois modes d’authentification selon votre contexte : session interactive (ntn login), token d’accès personnel (PAT) pour les scripts CI/CD, et OAuth 2.0 pour les intégrations distribuées. Les PAT se créent et se révoquent désormais depuis la section Développeur de votre sidebar (voir plus bas), sans passer par un site externe.

CLI et agents de code

Un aspect peu documenté mérite d’être souligné : le CLI est explicitement conçu pour être utilisé par des agents de code — Claude Code, Codex, Cursor — et pas seulement par des humains. Un agent peut s’authentifier, déployer un Worker et interroger des données Notion de façon autonome dans un pipeline CI/CD, sans interface graphique.

Portail développeur et barre développeur : tout depuis votre espace de travail

Mise à jour du 19 août 2026 : le portail développeur, jusqu’ici hébergé sur un site séparé, vit désormais directement dans votre espace de travail Notion. C’est le changement le plus concret pour le quotidien des builders API et no-code depuis le lancement de la plateforme.

Activer les fonctionnalités développeur

L’activation se fait en trois secondes. Ouvrez Paramètres → Développeur, puis activez Enable developer features. Deux éléments apparaissent aussitôt : une section Développeur dans votre sidebar et une barre développeur sur les pages que vous consultez. L’activation est disponible sur tous les plans, y compris le plan gratuit — seuls les Workers restent réservés aux plans Business et Enterprise.

La nouvelle entrée Développeur regroupe au même endroit ce qui obligeait auparavant à jongler entre l’interface Notion et le portail externe :

Workers — consulter vos Workers déployés et leur statut sans changer de site
Connexions — gérer les intégrations et applications connectées à votre workspace
Tokens d’accès personnel (PAT) — créer, consulter et révoquer vos tokens pour les scripts et pipelines CI/CD
Logs de déploiement — inspecter les exécutions run par run, directement dans Notion

Concrètement, vous gardez un œil sur vos Workers et vos logs sans jamais quitter votre espace de travail. Pour une équipe qui déploie régulièrement, c’est une friction en moins à chaque itération.

La barre développeur : copier n’importe quel ID en un clic

C’est l’ajout que j’attendais le plus. La barre développeur affiche, pour la page que vous consultez, l’identifiant de la page, de la base de données, du bloc, de l’espace de travail et de l’utilisateur courant. Vous copiez celui dont vous avez besoin — ou l’objet API complet — en un seul clic.

Jusqu’ici, récupérer l’ID d’une base impliquait de disséquer une URL Notion à la main, un point de friction classique pour quiconque débute avec l’API Notion. La barre développeur supprime cette étape. Pour les agents de code qui interrogent le serveur MCP Notion, c’est aussi un moyen rapide de vérifier à quel objet correspond un identifiant.

External Agents API : intégrer Claude Code, Cursor et Codex

Hub and spoke Notion Developer Platform — Notion au centre connecte Claude Code Anthropic, Codex OpenAI, Cursor IDE et Decagon via External Agents API, MCP 91 % tokens economises Notion comme hub d’orchestration : 4 agents natifs intégrés au lancement, spécification ouverte pour les agents custom. MCP 91 % plus efficace en tokens.

L’External Agents API est le composant le plus attendu de la Developer Platform 3.5. Il permet à des agents externes — Claude Code, Codex, Cursor, Decagon, ou un agent que vous avez développé — d’opérer dans votre workspace Notion comme des participants à part entière.

Ce que « participant à part entière » signifie concrètement

Avec l’API traditionnelle, un agent externe interagit avec Notion via des appels REST anonymes. Avec l’External Agents API, l’agent :

Dispose de sa propre identité et apparaît dans les @mentions
Peut être assigné à des éléments de base de données (tickets, tâches, issues)
Peut chatter dans des pages et voir l’historique de conversation
S’intègre dans les workflows d’approbation des Custom Agents

Un scénario typique : une issue GitHub entre dans Notion via un webhook, est automatiquement assignée à Claude Code, qui analyse le contexte dans les pages liées, propose un correctif dans la page de l’issue, et attend l’approbation de l’équipe avant d’ouvrir une PR.

Quatre agents intégrés nativement

Agent	Éditeur	Cas d’usage principal
Claude Code	Anthropic	Développement, revue de code, génération de documentation
Codex	OpenAI	Complétion de code, debugging, tests automatisés
Cursor	Cursor	IDE-first, refactoring, navigation de codebase
Decagon	Decagon	Support client, résolution de tickets, base de connaissances

Pour les équipes qui utilisent d’autres agents, la spécification de l’API est ouverte et documentée sur developers.notion.com.

Accès actuel : depuis le 20 août 2026, l’External Agents API est passée en bêta publique — plus de liste d’attente. Vous pouvez l’activer directement depuis app.notion.com/developers. Si vous préférez ne pas coder, vous pouvez toujours connecter Claude Code à Notion via le serveur MCP officiel. Le MCP a été amélioré avec la version 3.5 : la création et la mise à jour de bases de données sont désormais 91 % plus efficaces en tokens qu’auparavant (selon Notion, mai 2026).

Piloter un agent via l’API : sessions, streaming et gestion programmatique

C’est la nouveauté la plus structurante de l’été. Le 20 août 2026, Notion a fait passer ses Agent APIs en bêta publique. Concrètement, vous pilotez désormais un Custom Agent entièrement depuis du code, sans passer par l’interface.

Dialoguer avec un agent en temps réel

Le cœur de l’API repose sur la notion de session. Depuis votre application, vous pouvez :

Démarrer une conversation avec un Custom Agent (créer une session)
Streamer sa réponse au fil de l’eau, comme dans un chat
Soumettre une action que l’agent vous propose (approbation, choix, saisie)
Paginer l’historique d’événements d’une session pour reconstruire tout le fil

Cette API ouvre la porte aux intégrations que l’interface Notion ne permettait pas : embarquer un agent Notion dans un bot Slack, un outil interne ou un client mobile, avec le même comportement conversationnel que dans l’application.

Gérer vos agents par programmation

Au-delà du dialogue, l’API expose la gestion programmatique de vos agents :

Requêter les agents accessibles via l’endpoint de recherche d’agents
Récupérer les insights d’usage d’un agent (métriques de consommation)
Gérer les limites de crédits, l’activation/désactivation et la suppression d’un agent, individuellement ou par lot (batch)

Pour une équipe qui déploie plusieurs Custom Agents, c’est la brique qui manquait : plafonner les crédits d’un agent, en désactiver un temporairement ou auditer sa consommation devient une opération scriptable, intégrable dans vos propres tableaux de bord.

Deadline de migration — 30 septembre 2026. Si vous avez construit une intégration pendant l’alpha privée (routes agents, threads, messages ou chat), vous devez migrer vers les routes de bêta publique avant le 30 septembre 2026. Le changement est structurel : les nouvelles routes attendent des corps de requête JSON (et non des paramètres d’URL) et renvoient des sessions et des événements à la place des threads et messages. Passé cette date, les routes alpha cessent de fonctionner. Traitez cette migration comme prioritaire si vous êtes concerné.

Agent SDK : embarquer Notion dans vos outils

L’Agent SDK fonctionne dans la direction inverse de l’External Agents API. Plutôt que de faire entrer un agent externe dans Notion, il permet d’embarquer un agent Notion dans un autre outil : un CRM, MS Teams, Discord, ou une application maison.

Cas d’usage typiques

CRM → Notion : un commercial ferme une opportunité dans HubSpot. L’Agent SDK déclenche automatiquement un agent Notion qui crée la fiche client, génère le plan d’onboarding à partir des notes de vente, et envoie un résumé dans le canal Slack de l’équipe.

Support → Notion : un ticket de priorité haute arrive dans Zendesk. Le SDK déclenche l’agent Notion pour rassembler le contexte client depuis les bases de données, rédiger une réponse initiale basée sur la base de connaissances, et alerter l’équipe produit si un bug est détecté.

Depuis le 20 août 2026, l’Agent SDK est passé en bêta publique, en même temps que le reste des Agent APIs. La liste d’attente n’est plus nécessaire : vous y accédez directement via app.notion.com/developers. Notion recommande toutefois de valider vos workflows avant une mise en production à fort volume, la surface d’API pouvant encore évoluer pendant la bêta.

Workflow Agent SDK Notion — un outil CRM connecté via le cube Notion vers une notification chat, illustrant le déclenchement d'actions Notion depuis un outil externe

Webhooks entrants : déclencher vos workflows depuis l’extérieur

Les webhooks entrants comblent une lacune importante de l’écosystème Notion : jusqu’à présent, les automations et les agents ne pouvaient être déclenchés que depuis l’intérieur du workspace. Désormais, n’importe quelle application HTTP peut initier un workflow Notion.

Configuration en TypeScript

worker.webhook("onStripeEvent", {
  title: "Stripe Payment Webhook",
  execute: async (events) => {
    for (const event of events) {
      // Vérification de la signature
      const sig = event.headers["stripe-signature"];
      // Traitement et écriture dans Notion via context.notion
    }
  },
});

Après déploiement via ntn workers deploy, Notion génère une URL unique récupérable avec ntn workers webhooks list. Cette URL reçoit les événements POST de n’importe quel service : GitHub, Stripe, Zendesk, PagerDuty, ou votre propre backend.

Sécurité et gestion des erreurs

Deux règles essentielles pour une mise en production sereine :

Vérification de signature : la plupart des services signent leurs webhooks avec un secret partagé (HMAC-SHA256 pour GitHub, par exemple). Stockez ce secret comme variable d’environnement Worker et vérifiez chaque requête via event.rawBody et event.headers. Utilisez une comparaison à temps constant pour éviter les attaques temporelles.

Gestion des échecs : en cas d’erreur de vérification de signature, levez une WebhookVerificationError — Notion ne retentera pas la requête. Pour les autres erreurs, Notion retentera automatiquement. Après plusieurs échecs de vérification consécutifs, le webhook est bloqué automatiquement ; un redéploiement du Worker réinitialise le compteur.

MCP amélioré et API Markdown

Deux améliorations complémentaires accompagnent la Developer Platform 3.5 et méritent d’être mentionnées.

MCP 91 % plus efficace

Le serveur MCP officiel de Notion a été entièrement restructuré. La création et la mise à jour de bases de données y sont désormais 91 % plus efficaces en tokens qu’avec la version précédente, ce qui réduit sensiblement les coûts d’utilisation dans les pipelines d’agents. Pour les équipes qui utilisent déjà Claude Code ou Cursor avec le MCP Notion, la mise à jour est transparente.

API Markdown pour lire et écrire des pages

La nouvelle API Markdown permet de lire et d’écrire des pages Notion directement en Markdown, sans avoir à manipuler les blocs JSON natifs de l’API. Pour les agents de code, c’est un changement de paradigme : ils travaillent dans un format qu’ils maîtrisent nativement, sans couche de conversion intermédiaire.

Cette API s’ajoute à l’API Notion existante sans la remplacer — les deux coexistent et répondent à des besoins différents.

Comment démarrer aujourd’hui : par où commencer

Selon votre profil et vos priorités, voici l’ordre d’exploration que je recommande.

Pour démarrer immédiatement (tous plans)

Installez le CLI : curl -fsSL https://ntn.dev | bash — disponible sur tous les plans
Activez le MCP Notion dans Claude Code ou Cursor — 91 % plus efficace, disponible immédiatement
Déployez un Worker simple — commencez par un Database Sync depuis une API que vous utilisez déjà
Configurez un webhook entrant — connectez GitHub ou Stripe à votre workspace

Si vous gérez une équipe technique (plan Business ou Enterprise)

Activez l’External Agents API sur app.notion.com/developers — en bêta publique, sans liste d’attente depuis le 20/08
Pilotez vos Custom Agents par l’API (sessions, streaming, gestion des crédits) ou embarquez un agent Notion ailleurs via l’Agent SDK
Migrez vos intégrations alpha avant le 30 septembre 2026 si vous en avez développé pendant l’accès anticipé, et journalisez vos invocations Workers pour maîtriser les coûts en crédits

La configuration des Custom Agents Notion reste le point d’entrée le plus simple si vous ne voulez pas écrire de code. Les Workers et l’External Agents API sont des extensions pour les équipes qui ont besoin de plus de contrôle et de flexibilité.

Séquence de démarrage Notion Developer Platform — quatre blocs connectés représentant l'installation CLI, l'activation MCP, le déploiement d'un Worker et la configuration d'un webhook entrant

Ce qui change pour les power users

Avant apres Notion Developer Platform 3.5 — regles deterministes Make Zapier vs Workers TypeScript webhooks entrants agents externes Claude Code Codex Agent SDK Avant : automations cloisonnées et dépendantes d’outils tiers. Après : orchestration native d’agents, code TypeScript hébergé et déclenchement depuis n’importe quelle app HTTP.

La Developer Platform 3.5 déplace Notion d’un outil de productivité vers une couche d’orchestration d’agents. Les implications concrètes pour une équipe technique :

Avant la 3.5 : les automatisations Notion s’arrêtaient aux règles déterministes (si X, alors Y) ou dépendaient d’outils tiers comme Make ou Zapier pour les connexions externes. Les agents IA étaient cloisonnés dans l’interface Notion.

Après la 3.5 : un même workspace Notion peut recevoir des événements de systèmes externes (via webhooks), exécuter du code TypeScript (via Workers), orchestrer des agents internes et externes (via Custom Agents + External Agents API), et déclencher des actions dans d’autres outils (via Agent SDK).

Pour les automations Notion existantes, rien ne change — elles continuent de fonctionner. Les Workers et les agents sont des couches supplémentaires, pas des remplacements.

Mon avis après analyse

La Developer Platform 3.5 est l’une des annonces les plus techniques de Notion depuis l’ouverture de l’API publique en 2021. Le positionnement est clair : Notion veut devenir le workspace central autour duquel gravitent les agents IA, et non pas un outil parmi d’autres dans une stack d’automatisation.

Ce qui m’a surpris positivement : le CLI est disponible sur tous les plans, y compris le plan gratuit. C’est un choix délibéré pour attirer les développeurs indépendants avant de les convertir vers les plans Business. Le rythme s’est nettement accéléré : en trois mois, l’External Agents API et l’Agent SDK sont passés de l’alpha privée sur liste d’attente à la bêta publique (20 août 2026), avec en prime une API complète pour piloter les agents (sessions, streaming, gestion des crédits par lot). Notion tient son calendrier.

Ce qu’il faut surveiller : depuis le 11 août 2026, les Workers ne sont plus gratuits et chaque exécution consomme des Notion Credits. « 10 dollars pour 1 000 crédits » partagés avec les Custom Agents peut devenir coûteux si vous avez des Workers à haute fréquence d’exécution. Surveillez vos invocations via les logs de déploiement — désormais accessibles directement dans la section Développeur de votre sidebar.

La mise à jour du 19 août 2026 confirme la direction : en rapatriant le portail développeur et la barre développeur dans l’espace de travail, Notion réduit la friction pour les builders et signale que la plateforme n’est plus un chantier annexe. Le CLI, les webhooks et le portail sont disponibles sur tous les plans : c’est le bon moment pour expérimenter avant de passer aux Workers en production.

Sablier à moitié écoulé avec une fenêtre lumineuse à gauche et une pile de pièces avec un point d'interrogation à droite — symbolisant la fenêtre d'opportunité gratuite et l'incertitude tarifaire à venir

Questions fréquentes

Qu'est-ce que la Notion Developer Platform 3.5 ?

La Notion Developer Platform 3.5, annoncée le 13 mai 2026, est un ensemble de briques techniques permettant aux développeurs et aux agents IA d'étendre Notion sans gérer leur propre infrastructure. Elle regroupe cinq composants : Workers (runtime hébergé), External Agents API (intégration d'agents tiers), Agent SDK (embarquer un agent Notion ailleurs), CLI ntn (piloter Notion depuis le terminal) et les webhooks entrants (déclencher des workflows depuis n'importe quelle app).

Les Notion Workers sont-ils gratuits ?

Oui, pendant la phase bêta publique. Les Workers sont gratuits jusqu'au 11 août 2026, date à laquelle ils basculeront sur le système de Notion Credits (le même que les Custom Agents, à 10 dollars pour 1 000 crédits). Les Workers nécessitent un plan Business ou Enterprise. Le CLI ntn est disponible sur tous les plans, y compris le plan gratuit.

Comment connecter Claude Code à Notion comme agent externe ?

Depuis le 20 août 2026, l'External Agents API est en bêta publique : il n'y a plus de liste d'attente. Activez-la sur app.notion.com/developers, puis connectez Claude Code via un flux OAuth 2.0. Il devient alors un participant @-mentionnable dans votre workspace, assignable à des tâches. Si vous préférez ne pas coder, vous pouvez aussi connecter Claude Code via le serveur MCP officiel de Notion.

Quelle est la différence entre l'External Agents API et l'Agent SDK Notion ?

Les deux fonctionnent dans des directions opposées. L'External Agents API fait entrer des agents tiers (Claude Code, Codex, Cursor, Decagon) dans Notion : ils y deviennent des participants à part entière, assignables à des tâches et visibles dans les mentions. L'Agent SDK fait sortir un agent Notion vers d'autres outils : vous l'embarquez dans un CRM, MS Teams, Discord ou une app maison pour déclencher des actions Notion depuis un contexte externe.

Comment déployer un Worker Notion avec le CLI ?

Installez le CLI avec curl -fsSL https://ntn.dev | bash, authentifiez-vous avec ntn login, puis créez un Worker avec ntn workers new mon-worker. Écrivez votre logique TypeScript dans le fichier généré et déployez avec ntn workers deploy. Le Worker tourne ensuite dans un sandbox sécurisé hébergé par Notion. Vous pouvez inspecter les exécutions avec ntn workers runs list et ntn workers runs logs.

Quels agents externes sont supportés nativement par Notion ?

Au lancement de la Developer Platform 3.5, quatre agents externes sont intégrés nativement : Claude Code (Anthropic), Codex (OpenAI), Cursor, et Decagon. Les équipes qui utilisent d'autres agents peuvent construire leur propre intégration via la spécification ouverte de l'External Agents API. Des partenaires supplémentaires seront annoncés progressivement.

Les webhooks entrants Notion nécessitent-ils un serveur externe ?

Non, c'est précisément l'avantage des webhooks entrants de la Developer Platform. Vous définissez un handler webhook directement dans un Worker TypeScript, vous le déployez via le CLI, et Notion génère une URL unique. Aucun serveur externe, aucun Lambda, aucune infrastructure à gérer. GitHub, Stripe, Zendesk ou n'importe quel service HTTP peut envoyer des événements directement dans votre workspace Notion.

Comment activer le portail développeur dans la sidebar Notion ?

Depuis le 19 août 2026, le portail développeur vit directement dans votre espace de travail. Allez dans Paramètres, ouvrez la section Développeur, puis activez « Enable developer features ». Une entrée Développeur apparaît alors dans votre sidebar : vous y gérez vos Workers, vos connexions, vos tokens d'accès personnel et vos logs de déploiement sans quitter Notion ni ouvrir un site externe. L'activation des fonctionnalités développeur est disponible sur tous les plans, mais les Workers restent réservés aux plans Business et Enterprise.

Comment copier l'ID d'une page ou d'une base Notion en un clic ?

Une fois les fonctionnalités développeur activées, la barre développeur (developer bar) s'affiche sur la page que vous consultez. Elle vous permet de copier en un clic l'ID de la page, de la base de données, du bloc, de l'espace de travail ou de l'utilisateur courant, ou même l'objet API complet. Fini les manipulations d'URL pour extraire un identifiant : c'est un gain de temps direct pour tout travail d'intégration avec l'API Notion.

Comment piloter un Custom Agent Notion via l'API ?

Depuis le 20 août 2026, les Notion Agent APIs sont en bêta publique. Vous démarrez une session avec un Custom Agent, vous streamez sa réponse, vous soumettez une action et vous paginez l'historique d'événements de la session. L'API expose aussi la gestion programmatique : requêter les agents accessibles, récupérer leurs insights d'usage, et gérer les limites de crédits, l'activation ou la suppression, individuellement ou par lot. C'est ce qui permet d'embarquer un agent Notion dans un bot Slack, un outil interne ou un client mobile.

Y a-t-il une deadline pour migrer les intégrations Agent API alpha ?

Oui. Si vous avez construit une intégration pendant l'alpha privée (routes agents, threads, messages ou chat), vous devez migrer vers les routes de bêta publique avant le 30 septembre 2026. Le changement est structurel : les nouvelles routes attendent des corps de requête JSON au lieu de paramètres d'URL, et renvoient des sessions et des événements plutôt que des threads et des messages. Passé cette date, les routes alpha cessent de fonctionner.