Interface Web/Notifications, webhooks et calendriers
Notifications, webhooks et calendriers
v1.3.x · mis à jour 2026-09-15
Cette page couvre trois écrans de l’interface Web qui gèrent l’automatisation sortante et les alertes administratives : Notifications, Webhooks et Horaires.
Notifications
Le Notifications L’écran a trois parties :
Boîte de réception — un flux d’événements avec des filtres par catégorie, gravité (info / avertissement /
critique) et « seulement non lu ». Cliquer sur un élément le marque comme lu et crée un lien direct vers
son onglet ; il y a « Tout marquer comme lu ».
Matrice de livraison — lignes : catégories d’événements (groupes avec événements extensibles),
colonnes : canaux (interface Web, e-mail, Telegram, push). Chaque cellule est une case à cocher ; vous
peut définir une règle par groupe ou par événement. Les groupes “Importants” sont toujours activés pour le
Interface Web. Les canaux inactifs sont désactivés avec une indication de configuration.
Connexion Telegram — une liste de chats liés (étiquette, badge bloqué, « Détacher »)
et un Lien bouton via lien profond. Le canal e-mail nécessite une adresse
vérification.
Webhooks
Le Webhooks l’écran est des notifications HTTP sortantes. « + Create » : une URL et cases à cocher d’événement (sélection multiple ; une sélection vide est rejetée, turn.completed est pré-coché). Les lignes affichent l’URL et les événements abonnés, avec recherche et tri. Le type d’événement est envoyé dans le X-AIHummer-Event en-tête.
Le Horaires L’écran est le planificateur des tâches : une table (tâche, agent, canal, cron, prochaine exécution, statut) avec pause/reprise, modification et supprime. « + Créer » :
Gentil: repeating (une expression cron, par exemple 0 9 * * *), once (un
date/heure) ou reminder.
Agent cible et invite (ce qui est exactement envoyé), canal cible
(où va la réponse). Avancé : une substitution de charge utile JSON brute.
Voici comment on construit les actions programmées : « chaque jour de la semaine à 9h00, l’agent X publie le résultat du prompt Z sur le canal Y ».
Paramètres d’exécution avancés
Outre repeating, once et reminder, l’API d’administration
(/v1/admin/schedules) accepte le type interval — une exécution toutes
les interval_ms millisecondes à partir du point de référence anchor_at.
Dans le champ « Avancé (charge utile brute JSON) », à côté du prompt
habituel, vous pouvez ajouter un bloc runtime ("version": 1,
session_mode et "wake_mode": "now" sont obligatoires) qui fixe les
conditions d’exécution :
session_mode — isolated (chaque exécution dans un nouveau dialogue) ou
existing avec conversation_id (poursuivre le dialogue indiqué) ;
timeout_seconds — délai d’une exécution (48 heures par défaut ; 0
désactive le minuteur) ;
thinking — effort de raisonnement (off … xhigh), light_context —
un contexte allégé, tools_allow — noms exacts des outils autorisés ;
failure_alert — une alerte vers un canal (channel, target_ref.chat_id)
après after échecs consécutifs, avec une pause cooldown_ms ;
delete_after_run — supprimer la définition après l’exécution (le journal
des exécutions est conservé) ; best_effort — ne pas compter une livraison
non confirmée comme un échec.
Une telle exécution exige un agent cible et un prompt. Les planifications
importées d’un autre système sont créées en pause et activées séparément par le
propriétaire ; tant qu’elles ont des dépendances non résolues, elles ne peuvent
pas être activées.
Cette page couvre trois écrans de l'interface Web qui gèrent l'automatisation sortante et les alertes administratives : **Notifications**, **Webhooks** et **Horaires**.
## Notifications
Le **Notifications** L'écran a trois parties :
- **Boîte de réception** — un flux d'événements avec des filtres par catégorie, gravité (info / avertissement /
critique) et « seulement non lu ». Cliquer sur un élément le marque comme lu et crée un lien direct vers
son onglet ; il y a « Tout marquer comme lu ».
- **Matrice de livraison** — lignes : catégories d'événements (groupes avec événements extensibles),
colonnes : canaux (interface Web, e-mail, Telegram, push). Chaque cellule est une case à cocher ; vous
peut définir une règle par groupe ou par événement. Les groupes "Importants" sont toujours activés pour le
Interface Web. Les canaux inactifs sont désactivés avec une indication de configuration.
- **Connexion Telegram** — une liste de chats liés (étiquette, badge bloqué, « Détacher »)
et un **Lien** bouton via lien profond. Le canal e-mail nécessite une adresse
vérification.
## Webhooks
Le **Webhooks** l’écran est des notifications HTTP sortantes. « + Create » : une URL et **cases à cocher d'événement** (sélection multiple ; une sélection vide est rejetée, `turn.completed` est pré-coché). Les lignes affichent l'URL et les événements abonnés, avec recherche et tri. Le type d'événement est envoyé dans le `X-AIHummer-Event` en-tête.
**20 types d'événements** sont disponibles :
| Groupe | Événements |
|---|---|
| Tours et messages | `turn.completed`, `turn.failed`, `message.created`, `conversation.created` |
| Agents | `agent.created`, `agent.updated`, `agent.deleted` |
| Plugins et chaînes | `plugin.installed`, `plugin.removed`, `channel.added`, `channel.removed` |
| Espaces de travail | `workspace.created` |
| Horaires | `schedule.created`, `schedule.updated`, `schedule.deleted`, `schedule.fired` |
| Approbations | `approval.requested`, `approval.resolved` |
| Mémoire | `memory.stored`, `memory.captured` |
## Horaires
Le **Horaires** L’écran est le planificateur des tâches : une table (tâche, agent, canal, cron, prochaine exécution, statut) avec pause/reprise, modification et supprime. « + Créer » :
- **Gentil**: `repeating` (une expression cron, par exemple `0 9 * * *`), `once` (un
date/heure) ou `reminder`.
- **Agent cible** et **invite** (ce qui est exactement envoyé), **canal cible**
(où va la réponse). Avancé : une substitution de charge utile JSON brute.
Voici comment on construit les actions programmées : « chaque jour de la semaine à 9h00, l’agent X publie le résultat du prompt Z sur le canal Y ».
### Paramètres d’exécution avancés
Outre `repeating`, `once` et `reminder`, l’API d’administration
(`/v1/admin/schedules`) accepte le type **`interval`** — une exécution toutes
les `interval_ms` millisecondes à partir du point de référence `anchor_at`.
Dans le champ **« Avancé (charge utile brute JSON) »**, à côté du `prompt`
habituel, vous pouvez ajouter un bloc `runtime` (`"version": 1`,
`session_mode` et `"wake_mode": "now"` sont obligatoires) qui fixe les
conditions d’exécution :
- `session_mode` — `isolated` (chaque exécution dans un nouveau dialogue) ou
`existing` avec `conversation_id` (poursuivre le dialogue indiqué) ;
- `timeout_seconds` — délai d’une exécution (48 heures par défaut ; `0`
désactive le minuteur) ;
- `thinking` — effort de raisonnement (`off` … `xhigh`), `light_context` —
un contexte allégé, `tools_allow` — noms exacts des outils autorisés ;
- `failure_alert` — une alerte vers un canal (`channel`, `target_ref.chat_id`)
après `after` échecs consécutifs, avec une pause `cooldown_ms` ;
- `delete_after_run` — supprimer la définition après l’exécution (le journal
des exécutions est conservé) ; `best_effort` — ne pas compter une livraison
non confirmée comme un échec.
Une telle exécution exige un agent cible et un prompt. Les planifications
importées d’un autre système sont créées en pause et activées séparément par le
propriétaire ; tant qu’elles ont des dépendances non résolues, elles ne peuvent
pas être activées.
## Suivant
- [Chaînes](/fr/v1.0/webui/channels) — où vont les messages et les alertes.
- [Déclencheurs entrants](/fr/v1.0/api/inbound-triggers) — webhooks dans le contexte de l'API.
- [Observabilité](/fr/v1.0/operations/observability) — quels événements comptent.