À l'instant où ça se produit,
votre serveur le sait
Les événements de modération poussés vers votre serveur à l'instant où ils se produisent : détections de spam, bannissements, arrivées et plus encore — chaque livraison signée en HMAC, dédupliquée et relancée selon un calendrier jusqu'à ce que votre endpoint la confirme.
- Des événements en temps réel
- Charges utiles signées en HMAC
- Des relances jusqu'à livraison
Sept événements, tout droit sortis du moteur
Abonnez chaque endpoint exactement aux événements dont vous avez besoin — des verdicts de spam aux changements d'appartenance.
spam.detectedmessage.suspicioususer.banneduser.kickeduser.muteduser.joineduser.leftChaque événement voyage dans une enveloppe JSON compacte : id, type, created_at, group_id et les données de l'événement — l'id reste stable d'une relance à l'autre, si bien que la déduplication tient en une seule recherche d'ensemble.
Le calendrier de relances, exactement tel qu'il s'exécute
Six tentatives sur environ huit heures — de quoi encaisser un déploiement, un redémarrage ou une panne complète de votre côté.
0Instantané+1m+5m+30m+2h+6hDernière tentativeUne livraison sur laquelle bâtir
Livraison au moins une fois
Chaque événement est livré au moins une fois. Votre endpoint confirme par un 2xx quelconque — tout le reste retourne dans la file de relances.
Des id stables pour la déduplication
Chaque événement a un id stable qui survit aux relances. La déduplication de votre côté est une simple recherche, pas une heuristique.
Pas d'endpoints zombies
Un endpoint qui échoue pendant des jours est désactivé automatiquement — et vous recevez un message privé Telegram plutôt qu'un trou silencieux dans vos données.
Ping de test
Un événement de test en un clic, signé comme un vrai — vérifiez votre gestionnaire avant qu'un seul vrai événement n'en dépende.
Historique inspectable
Historique de livraison complet par endpoint : chaque tentative, statut et horodatage — déboguer votre destinataire ne relève jamais de la devinette.
HTTPS uniquement, toujours signé
Les endpoints doivent être des URL HTTPS publiques, et chaque charge utile est signée. Le transport et l'authenticité sont tous deux couverts.
Vérifiez chaque livraison
Trois lignes de votre côté — et personne ne peut falsifier ni rejouer un événement.
# X-Telm-Signature: v1=<hex>
expected = hmac_sha256(secret, timestamp + "." + body)
valid = constant_time_eq("v1=" + hex(expected), header)Poussez, n'interrogez pas
Interroger une API vous dit ce qui s'est passé au moment où vous demandez ; les webhooks vous le disent à l'instant où cela se produit. Enregistrez un endpoint HTTPS, choisissez les événements qui vous intéressent, et Telm se met à les pousser vers votre serveur en JSON — une vague de spam, un bannissement, un raid d'arrivées — à la seconde où le moteur agit.
Chaque livraison est signée. L'en-tête X-Telm-Signature transporte un HMAC-SHA256 de l'horodatage et du corps, calculé avec le secret de votre endpoint, pour que votre serveur puisse vérifier à la fois l'authenticité et la fraîcheur en trois lignes de code. Les charges utiles ne circulent qu'en HTTPS.
La livraison est conçue pour l'internet réel, où les destinataires tombent en panne. Les événements sont livrés au moins une fois, avec un id stable pour la déduplication ; les échecs sont relancés selon un calendrier croissant — immédiatement, puis après 1 et 5 minutes, 30 minutes, 2 et 6 heures. Un endpoint qui continue d'échouer pendant des jours est désactivé automatiquement, et vous recevez un message Telegram à ce sujet plutôt qu'un silence.
Tout est inspectable : envoyez un ping de test avant la mise en production, et parcourez l'historique de livraison — tentative par tentative, statut par statut — chaque fois que vous devez déboguer votre côté du tuyau.
Questions fréquentes
Comment vérifier qu'un événement provient réellement de Telm ?
Chaque livraison porte un en-tête X-Telm-Signature : un HMAC-SHA256 de « timestamp.body » calculé avec le secret de votre endpoint. Recalculez-le de votre côté, comparez en temps constant, et rejetez tout ce qui a plus de quelques minutes pour écarter les rejeux (replays).
Que se passe-t-il si mon serveur est en panne au moment où un événement se déclenche ?
Telm relance selon un calendrier croissant — immédiatement, puis après 1 minute, 5 minutes, 30 minutes, 2 heures et 6 heures. Toute réponse 2xx compte comme livrée. Les événements portent un id stable, de sorte qu'une relance ne devient jamais un doublon dans votre système.
Un endpoint défaillant peut-il inonder indéfiniment ?
Non. Un endpoint qui échoue une vingtaine de fois d'affilée sans aucun succès pendant trois jours est désactivé automatiquement, et vous recevez une notification Telegram. Corrigez votre côté et réactivez-le en un clic.
Comment tester mon intégration avant la mise en production ?
Envoyez un ping de test à n'importe quel endpoint directement depuis le tableau de bord ou l'API — il arrive signé exactement comme un vrai événement. L'historique de livraison montre chaque tentative avec son statut.
Quels plans incluent les webhooks ?
Les webhooks font partie de l'offre API complète, incluse dans les plans Pro et Business.
Fonctionnalités connexes
Découvrez d'autres façons dont Telm peut aider votre communauté