Le difficile n'est jamais l'app toute seule, c'est l'interface entre elle et ton instance n8n. Cette page traite quatre tâches et montre chaque fois les deux côtés : ce qui se passe dans n8n, et ce qui se passe dans l'app.
Deux informations suffisent : l'adresse de ton instance n8n et une clé API n8n. Les deux restent sur l'appareil — la clé va dans le trousseau iOS, pas sur nos serveurs.
https://mon-instance.app.n8n.cloud — sans chemin après.C'est que l'API publique n'est pas activée sur ton instance. Certaines offres d'hébergement et certaines configurations auto-hébergées la laissent désactivée par défaut. Sur une instance auto-hébergée, elle s'active dans les paramètres n8n ou par variable d'environnement ; sur une offre hébergée, cela dépend de la formule.
Sans API publique, aucune app ne peut parler à ton instance — la nôtre non plus. Ce n'est pas une limite de WorkflowBuddy, c'est l'interface elle-même.
Deux causes fréquentes : la clé API a été tronquée à la copie, ou l'URL comporte un chemin de trop. Saisis l'adresse de base seule — pas l'URL de l'éditeur, et pas de /api/v1 à la fin.
Dans le trousseau iOS de ton appareil. Si tu le souhaites, Face ID ou Touch ID protège l'accès à l'app et l'affichage de la clé. Nous ne stockons pas ta clé API n8n.
Tu définis une règle de surveillance par workflow : ce qui est signalé, à quelle fréquence la vérification a lieu et quand il faut se taire. Le reste est assuré par la surveillance sur notre serveur — même quand l'app est fermée.
Rien. Et c'est voulu : WorkflowBuddy interroge l'API n8n sur les exécutions de tes workflows. Aucun nœud d'erreur n'est injecté, aucun workflow n'est modifié, rien n'est installé dans ton instance.
Cela veut dire aussi qu'un workflow créé demain peut être surveillé tout de suite — sans préparation.
Les alertes d'erreur pour ton workflow le plus important sont l'entrée gratuite Free — un workflow, sans limite de durée. La surveillance de tous les workflows ainsi que les types d'incident annulé et bloqué relèvent de Premium Premium, tout comme les heures calmes et l'intervalle de vérification plus fin.
Reprends trois points dans l'ordre : les notifications de WorkflowBuddy sont-elles autorisées dans les réglages iOS ? Une règle de surveillance est-elle active pour ce workflow précis ? Et est-ce tombé pendant tes heures calmes ?
Si le silence persiste, envoie-toi une notification de test depuis la règle. Si elle arrive, le chemin de livraison est bon.
Tu choisis entre 5, 15, 30 et 60 minutes. La vérification a lieu sur notre serveur, pas sur le téléphone — la notification arrive donc même quand l'app est fermée. La mention « minimum iOS : 15 min » dans l'app ne concerne que l'actualisation de l'affichage en arrière-plan, pas les alertes.
En gratuit, la surveillance tourne avec l'intervalle par défaut de 15 minutes ; choisir l'intervalle relève de Premium. Si tu as besoin de la seconde près, prends l'API Push : c'est alors le workflow lui-même qui signale, au moment où cela se produit.
Une exécution qui a démarré et qui tourne encore après un délai que tu as fixé. En général, elle attend un service externe qui ne répond plus. Les approbations ouvertes ne comptent expressément pas : elles ont le droit d'attendre.
Quand c'est ton workflow qui sait le mieux qu'il y a quelque chose à dire : une clé depuis l'app, un nœud HTTP Request ordinaire dans n8n — pas de nœud Code, pas de signature.
wb_ et reste ensuite dans le trousseau de cet appareil.Ajoute un nœud HTTP Request, méthode POST, et transmets la clé dans un en-tête. Un simple JSON suffit comme corps :
POST https://companion.amelus.de/api/notify
Authorization: Bearer wb_...
Content-Type: application/json
{
"title": "Échec de la facturation",
"message": "L'exécution 4711 s'est arrêtée à l'étape 3",
"severity": "warning"
}severity est optionnel et accepte info, warning et critical ; sans indication, c'est info.
50 messages par jour sont inclus gratuitement Free, Premium porte la limite à 500 par jour Premium. Les deux se comptent par appareil.
La clé est inconnue ou a été révoquée. Lors d'un renouvellement, l'ancienne clé devient immédiatement invalide — il faut alors aussi remplacer le credential dans n8n. Vérifie également que l'en-tête contient bien Bearer devant la clé.
Le quota journalier ou par minute est épuisé. La réponse contient un en-tête Retry-After qui indique à partir de quand cela refonctionne. Un workflow dans une boucle en est la cause habituelle.
Notre serveur a donc accepté le message et l'a transmis, et c'est iOS qui l'a supprimé. Presque toujours, les notifications de WorkflowBuddy sont désactivées. L'app te le dit désormais dans l'écran API Push, au lieu d'annoncer un succès sans livraison.
Oui, autant que tu veux. Crée-la une fois dans n8n comme credential Header Auth : tous les workflows y accèdent et un changement de clé se fait à un seul endroit.
Le workflow s'arrête et te demande ; ta réponse le poursuit ou l'interrompt. En une phrase : une notification sur le téléphone, une touche, et ça repart — sans ouvrir n8n.
Deux nœuds standard, pas de code.
https://companion.amelus.de/api/approval, en-tête Authorization: Bearer wb_... (la même clé que pour l'API Push). Le corps est défini comme Expression :{{ JSON.stringify({
title: 'Facture 4711',
message: 'Autoriser le paiement de 2 400 € ?',
resumeUrl: $execution.resumeUrl,
expiresAt: new Date(Date.now() + 60*60*1000).toISOString()
}) }}{{ $json.query.decision }}, qui distingue les valeurs approve et reject.expiresAt est renseigné — le temps restant.Aucune clé supplémentaire à configurer : les approbations utilisent la même clé API Push, mais disposent de leur propre quota.
Nous sommes tombés dans chacun d'eux ; chacun coûte une demi-soirée :
$execution.resumeUrl telle quelle. N'ajoute rien, surtout pas ?decision=approve. Depuis n8n 2.33, l'URL de reprise porte déjà une signature ; un second ? la détruit, n8n répond 401, et rien de suspect n'apparaît dans le journal de l'instance. Le paramètre de décision, c'est l'endpoint qui le pose.
$execution.resumeUrl se retrouve littéralement dans la requête et l'approbation n'a nulle part où revenir.
5 approbations par jour sont gratuites Free — de quoi essayer sur un vrai workflow — et Premium porte la limite à 200 par jour Premium. Ce quota est séparé de celui des messages ordinaires : un workflow bavard ne peut donc pas te priver d'une approbation.
Directement de l'appareil vers ta propre instance n8n. Notre serveur ne fait que transmettre la notification et ne stocke jamais l'adresse de reprise. L'app, de son côté, n'appelle que des adresses dont l'hôte appartient à une instance que tu as configurée — une adresse glissée en douce ne mène nulle part.
Aucun problème. La demande est enregistrée dès sa réception, et non au moment où tu la touches. Elle reste sur le tableau de bord sous forme de carte tant qu'elle est ouverte.
L'exécution a été poursuivie entre-temps, le délai a expiré ou elle a été annulée. Cause la plus fréquente en test : le workflow a été relancé dans l'éditeur (voir le piège 3).
L'app refuse délibérément tout appel vers un hôte étranger. Cela arrive lorsque le workflow tourne sur une instance qui n'est pas (encore) configurée dans l'app — ou lorsque cette instance y figure sous une autre adresse, interne plutôt que publique par exemple.
C'est que le workflow n'a pas envoyé d'expiresAt. n8n ne communique pas de lui-même le délai du nœud Wait, c'est donc au workflow de l'envoyer — sans lui, l'app préfère afficher la demande sans compte à rebours plutôt que d'inventer une échéance.
Écris-nous à info@amelus.de ou utilise le formulaire de contact. Ce qui manque ici a le plus souvent sa place sur cette page — tes remarques sont les bienvenues.