S’exécute surWrit CloudDesktopAuto-hébergé
Sur cette page
Neuf canaux, et une grille.
Deux systèmes différents partagent le mot « notification », et les confondre coûte un après-midi. Les canaux sont ce qu’un moniteur ou une automatisation déclenche. Les préférences sont ce que la plateforme vous dit. Cette page les sépare.
partage ▸ deux systèmes
Duquel parlez-vous ?
Les deux vivent dans les réglages, les deux disent « notifications », et ils ne partagent pas la même liste de canaux. Commencez ici :
| Canaux de moniteurs et d’automatisations | Neuf fournisseurs, configurés une fois pour l’organisation. Un moniteur détecte un changement, ou une automatisation atteint une étape de notification, et le message part. Les destinataires s’écrivent « channel:id ». |
| Préférences de notification de la plateforme | Six canaux sur sept catégories, par utilisateur. Sécurité, facturation, équipe, runs, agents, marketplace et support — ce que Writ vous dit sur votre propre compte. |
canaux ▸ neuf
Configurer un canal.
Configurez chacun une fois pour l’organisation, puis ajoutez-y des destinataires. Chaque canal a un envoi de test.
| Canal | Clé API | Ce que vous fournissez |
|---|---|---|
| Pushover | pushover | Token d’application et clé utilisateur. Optionnellement un titre, un message, une priorité de −2 à 2, un son, un intitulé de lien, et HTML activé ou non. |
| E-mail (SMTP) | email | Hôte, port, nom d’utilisateur, mot de passe, adresse d’expédition, nom d’expéditeur, et TLS activé ou non. |
| E-mail (Google Workspace) | email | Connexion via OAuth au lieu de SMTP. La configuration indique quel fournisseur est actif et quel compte est connecté, et vous pouvez le déconnecter. |
| SMS | twilio | Account SID, auth token, et un numéro d’envoi au format E.164. L’auth token n’est jamais renvoyé une fois enregistré. |
whatsapp | Un numéro d’envoi au format whatsapp:+1234567890. Il s’appuie sur les mêmes identifiants que le SMS : il ne devient utilisable qu’une fois les deux configurés. | |
| Signal | signal | L’URL d’un serveur REST signal-cli que vous exploitez vous-même, plus le numéro d’expéditeur au format E.164. |
| Slack | slack | Une URL de webhook de canal par destinataire. L’API ne renvoie jamais que l’hôte, jamais l’URL complète. |
| Discord | discord | Une URL de webhook de canal par destinataire. L’API ne renvoie jamais que l’hôte, jamais l’URL complète. |
| Telegram | telegram | Le token que BotFather vous donne, plus un chat id par destinataire. Le token est masqué dans les réponses. |
| Webhook | webhook | Votre propre URL, avec en-têtes personnalisés et vérification de signature HMAC en option. Les livraisons sont réessayées avec un délai exponentiel. |
Les identifiants entrent et ne ressortent jamais : l’auth token SMS n’est pas renvoyé une fois enregistré, les URL Slack et Discord n’apparaissent que par leur hôte, et le token Telegram est masqué. Pour en changer un, remplacez-le — vous ne pouvez pas le relire pour le vérifier.
Le canal webhook signe chaque livraison. Le contrat de signature exact, les noms d’en-têtes et un exemple de vérification vivent sur Webhooks.
Webhooks →destinataires ▸ channel:id
Désigner qui joindre.
Une fois qu’un canal a des destinataires, une automatisation y fait référence par des chaînes "channel:id" — par exemple ["pushover:1","email:3"]. Un seul appel liste tous les destinataires de tous les canaux, chacun avec son identifiant masqué, et c’est ce qu’affiche un sélecteur.
recipients
{
"channels": ["pushover", "email"],
"recipients": ["pushover:1", "email:3"]
} list-recipients.sh
curl https://api.usewrit.app/api/notifications/recipients/all \
-H "Authorization: Bearer $WRIT_API_KEY" Attention : la clé du SMS est twilio, pas sms — c’est la valeur que l’API attend dans une liste de canaux. Dans la grille de préférences plus bas, la même idée s’écrit sms. Ce sont deux systèmes différents.
contrôles ▸ toute l’organisation
Contrôles de livraison.
Ils s’appliquent à toute l’organisation, pas par canal — pour qu’une nuit agitée ne devienne pas cent messages :
| Contrôle | Ce qu’il fait |
|---|---|
| Heures calmes | Une heure de début et une de fin pendant lesquelles rien n’est livré. |
| Limitation de débit | Un nombre maximal de messages par période. |
| Regroupement | Rassemble ce qui arrive dans une fenêtre, en minutes, et l’envoie en un seul message. |
| Alertes d’erreur d’agent | Prévenir quand un agent échoue, avec un seuil et un délai en minutes. |
| Alertes de santé de cible | Prévenir quand une cible échoue en série, avec un seuil et un intervalle de contrôle. |
| Alertes de santé système | Prévenir quand un agent se déconnecte, après un délai. |
placeholders ▸ alertes de changement
Ce que vous pouvez mettre dans le message.
Les notifications de changement injectent ces placeholders dans votre modèle de message. Regroupés par la question à laquelle ils répondent :
| Ce qui était surveillé | {url} {target_id} {target_name} {selector} {selector_name} {agent_id} {agent_platform} {change_count} {check_count} |
| Ce qui a changé | {diff} {detected_change} {previous_content} {new_content} {content_hash} {previous_hash} |
| Quand | {timestamp} {date} {time} |
Un placeholder inconnu est laissé tel quel plutôt que de faire échouer l’envoi : une faute de frappe vous coûte un token littéral dans le message, pas une alerte perdue. Les aperçus sont tronqués : {diff} et {detected_change} à 500 caractères, {previous_content} et {new_content} à 200.
relais ▸ depuis un appareil
Un appareil relié qui passe la main au cloud.
Un appareil exécute les automatisations en local, mais certains canaux ont besoin du cloud pour livrer. Seuls e-mail, pushover, SMS, WhatsApp et Signal passent par le relais ; webhook, Slack, Discord et Telegram sont livrés par l’appareil lui-même, puisqu’il peut les joindre directement.
relay.sh
curl -X POST https://api.usewrit.app/api/notifications/relay \
-H "Authorization: Bearer $WRIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"channels": ["email", "pushover"],
"recipients": ["email:3", "pushover:1"],
"title": "Price dropped",
"message": "Now $41.00, was $49.00.",
"url": "https://example.com/product/42"
}' | Champ | Règle |
|---|---|
channels | De 1 à 8, et sous-ensemble des canaux relayables. Tout le reste est refusé en 400. |
recipients | Références de destinataires, les mêmes chaînes « channel:id ». |
title | Jusqu’à 200 caractères. |
message | De 1 à 4000 caractères. |
priority | Optionnel. |
url | Lien optionnel, jusqu’à 2000 caractères. |
email_subject | Optionnel, jusqu’à 300 caractères. |
La livraison part vers vos propres destinataires configurés — jamais vers une adresse arbitraire fournie dans l’appel. Les notifications relayées sont limitées à 120 par heure et par organisation, pour qu’une automatisation locale instable ne vide pas un budget SMS en quelques minutes.
préférences ▸ l’autre grille
Préférences de notification de la plateforme.
Voici le second système : ce que Writ vous dit, par utilisateur, sur GET et PUT /api/notifications/preferences. Autre jeu de canaux, autre finalité.
Six canaux
Pas les mêmes neuf que plus haut :
in_app | La cloche et la boîte de réception dans Writ. |
email | L’e-mail de votre compte. |
sms | Un point de contact personnel sur votre ligne de préférences. |
whatsapp | Le même point de contact personnel. |
signal | Le même point de contact personnel. |
pushover | Votre propre clé utilisateur Pushover. |
Sept catégories
Les événements sont regroupés pour raisonner sans lire chaque ligne :
| Sécurité | Activité de sécurité du compte. |
| Facturation et paiements | Solde, reçus, problèmes de paiement. |
| Équipe | Invitations et appartenance. |
| Automatisations et runs | Ce qu’ont fait vos workflows. |
| Agents et appareils | Ce qu’ont fait vos machines. |
| Marketplace et créateur | Annonces, installations, revenus. |
| Support | Activité des tickets. |
Quatre règles qui surprennent
- La grille est creuse. Seuls les canaux qu’un événement propose vraiment sont affichés — une case vide n’est pas un réglage qui vous manque.
- Certaines cases sont verrouillées et toujours actives : alertes de sécurité, problèmes de paiement et invitations d’équipe. L’API n’enregistre aucune dérogation pour celles-là.
- Certains événements sont volontairement en e-mail uniquement.
- Les alertes de changement par moniteur vivent délibérément hors de cette grille, avec leurs propres réglages par cible.
Le build auto-hébergé livre un catalogue réduit, sans les événements de facturation ni de marketplace — il n’y a ni facturation ni marketplace dans ce build pour vous en parler.
référence ▸ suite
Continuer
Ce qui détecte le changement qui déclenche l’alerte.
→ WebhooksLe contrat de signature, vérifié.
→ Vos propres machinesLes appareils qui relaient via le cloud.
→ Utilisateurs et équipesQui reçoit quels événements plateforme.
→ Writ DesktopDes automatisations qui s’exécutent et alertent en local.
→ Auto-hébergementLe catalogue réduit du build open-core.
→faq