Dans l’actualité visible d’Aurabase, le signal récent est côté SDK : la page d’accueil annonce la publication de @aurabase/js v0.5.1 et du crate Rust v0.1.1. Elle ne donne pas de date pour ces publications. Les informations produit disponibles ne documentent pas de mécanisme de webhooks signés, de retentatives automatiques ni de diffusion SMS ou push. C’est une distinction importante : disposer d’un backend et d’un service Notifications ne suffit pas à conclure que ces garanties sont intégrées.

Pour les équipes qui construisent un système de webhooks backend, la question utile n’est donc pas seulement « comment envoyer un POST ? ». Il faut garantir l’intégrité du message, la résistance aux rejeux, la reprise après panne et une sémantique claire en cas de livraison répétée. Les notifications push, email et SMS ajoutent ensuite des états et des contraintes propres à chaque canal.

Signer le corps exact, pas une représentation reconstruite

Un schéma courant consiste à calculer une signature HMAC avec un secret partagé. Le producteur signe le corps brut de la requête, puis transmet la signature et un horodatage dans des en-têtes dédiés. Le destinataire recalcule la signature sur les octets reçus et compare les valeurs en temps constant. Si le framework transforme le JSON avant le calcul, l’ordre des clés ou l’encodage peut changer et faire échouer une vérification pourtant légitime.

L’horodatage limite la durée pendant laquelle une requête capturée peut être rejouée. Le destinataire doit rejeter les messages trop anciens ou trop éloignés de son horloge, et conserver brièvement les identifiants déjà traités. Une signature valide ne rend pas un message unique : elle prouve qu’il a été produit par quelqu’un qui connaît le secret, pas qu’il n’a jamais été reçu auparavant.

Prévoyez aussi la rotation des secrets. Une période de transition, où l’ancien et le nouveau secret sont acceptés, évite de casser tous les consommateurs au même instant. Ne placez jamais les secrets dans les journaux, les URL ou les messages d’erreur renvoyés au client.

La livraison fiable commence avant l’appel réseau

Un envoi directement déclenché après une écriture en base crée un cas classique de perte : la transaction réussit, puis le processus tombe avant l’appel HTTP. À l’inverse, l’appel peut réussir alors que le producteur ne reçoit pas la réponse, ce qui entraîne un doublon au prochain essai. Les systèmes distribués ne peuvent pas traiter une réponse réseau ambiguë comme une preuve certaine d’échec.

Le motif de l’outbox transactionnelle réduit ce risque. La même transaction enregistre le changement métier et un événement à livrer. Un worker lit ensuite les événements en attente, effectue l’envoi et enregistre le résultat. La file doit survivre au redémarrage. Pour les tentatives, utilisez un délai progressif avec une limite, puis une file d’échec consultable et rejouable. Une clé d’idempotence stable, transmise au destinataire, aide celui-ci à éviter de refaire une action déjà appliquée.

Les réponses HTTP ne racontent pas toute l’histoire. Distinguez les erreurs temporaires des erreurs permanentes, fixez des délais d’attente et surveillez l’âge des événements en attente, le taux d’échec et le nombre de tentatives. Les journaux doivent permettre de suivre un événement sans exposer son contenu sensible ni ses secrets de signature.

Ne pas confondre webhooks et notifications aux utilisateurs

Un webhook est un contrat machine à machine : il transporte un événement vers un endpoint contrôlé par un intégrateur. Une notification email, SMS ou push vise un utilisateur et dépend de préférences, de consentements, de limites d’envoi et d’accusés de réception propres au canal. Réunir ces tâches dans un système de diffusion ne supprime pas leurs différences. Il faut conserver des états distincts pour « accepté », « remis au fournisseur », « délivré » ou « échec », selon les informations effectivement disponibles.

Dans une architecture, la logique métier peut créer des événements, tandis qu’un worker séparé gère la file et les tentatives. Les fonctions Edge peuvent faire partie du parcours applicatif, mais les informations produit publiées ne précisent pas ici leur rôle dans un pipeline de webhooks, ni l’existence d’une file de livraison intégrée. Vérifiez la persistance, les limites d’exécution et les garanties de reprise avant de leur confier ce rôle. Pour choisir entre diffusion temps réel vers une interface et livraison durable à un consommateur, le comparatif entre CDC, WebSockets et realtime pose un cadre utile, même si les webhooks ont leurs propres exigences.

Ce que le digest permet de conclure

La publication des SDK TypeScript/React et Rust est un signal de mouvement dans l’écosystème, pas une annonce de capacités de webhook. Aurabase documente PostgreSQL dédié, Auth, stockage compatible S3, Edge Functions, Realtime, AI et Notifications, ainsi qu’un moteur Rust pour le routage, la limitation de débit et la vérification de jetons. Ces éléments ne prouvent pas, à eux seuls, que la signature HMAC des webhooks, les retries durables ou les envois SMS et push sont fournis par la plateforme.

Avant de choisir un système webhooks backend, demandez des garanties vérifiables : format de signature, prévention des rejeux, stratégie de rotation, politique de retentative, conservation des événements et comportement à l’expiration. Pour les notifications push, email et SMS, vérifiez séparément quels canaux sont réellement pris en charge et quels états de livraison sont exposés. C’est à ce niveau de détail que l’on distingue une API qui déclenche un envoi d’un système de diffusion exploitable en production.