Tester une règle
Lesquels de vos messages récents cette règle aurait attrapés. Elle ne change rien.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
POST /rules/{id}/test
Lesquels de vos messages récents cette règle aurait attrapés. Elle ne change rien.
Exemple
Requiert rules:read. Une exécution à blanc lit une boîte et n'écrit rien : ce n'est donc pas une opération rules:write. days vaut 30 par défaut et va jusqu'à 365, limit vaut 50 par défaut et va jusqu'à 200, et threadIds teste des fils nommés au lieu d'une fenêtre.
curl -X POST "$OE/rules/rul_7f3a1c94e05d3862c1f0a44b/test" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "days": 30, "limit": 50 }'{ "object": "rule_test", "ruleId": "rul_7f3a1c94e05d3862c1f0a44b", "scanned": 50, "matched": 3, "wouldApply": ["label:USER_RECEIPTS", "archive"], "messages": [ { "threadId": "thr_5d31c2a8…", "from": "[email protected]", "subject": "Your receipt", "receivedAt": "2026-08-28T10:00:00.000Z" } ], "warnings": [{ "code": "forward_unverified", "value": "[email protected]" }]}C'est le même moteur que celui qui s'exécute sur le chemin de livraison qui répond ici. C'est un seul module, délibérément pur (pas de base de données, pas de réseau), afin que l'écran des réglages, l'exécution à blanc et le gestionnaire SMTP ne puissent pas être en désaccord sur le fait qu'une règle corresponde. Un aperçu écrit deux fois, ce sont deux réponses à une seule question, et celle que l'on montre à une personne est celle qui est fausse.
Borné par construction : au plus 200 messages sur au plus un an. Cela s'exécute dans un Worker doté d'un budget de temps réel, et un balayage non borné est une requête qui meurt à mi-chemin sans rien à montrer.
Une règle désactivée peut tout de même être testée. C'est tout l'intérêt : l'écrire, la tester, puis l'activer.
warnings est l'endroit où apparaît une règle qui s'analyse correctement mais ne se comportera pas bien. Une adresse de transfert que personne n'a confirmée est celle que vous rencontrerez. Un avertissement n'interrompt jamais le test : l'intérêt d'une exécution à blanc est de signaler tout ce qu'elle a trouvé en une seule passe plutôt que d'échouer au premier obstacle.
Il n'existe pas d'« exécuter ceci sur ma boîte »
Il n'existe délibérément pas de POST /rules/{id}/run, et il n'y en aura pas. Appliquer une règle rétroactivement à toute une boîte est non borné, irréversible et sans annulation possible (une action trash sur dix ans de courrier tient en un appel sans seconde chance), et le chemin d'écriture qu'elle devrait emprunter fusionne dans le fil stocké, ce qui remonterait en haut de la boîte de réception chaque message touché, comme effet de bord d'un rangement.
Cet endpoint est la moitié honnête de cette demande : il répond à « qu'est-ce que cela aurait fait », qui est la question, et ensuite vous classez les messages que vous visiez réellement avec PATCH /threads/{id}.