Tester ses webhooks en local

Votre endpoint webhook tourne sur localhost, lahsab ne peut pas l’atteindre. Plutôt qu’un tunnel tiers, le CLI inverse le sens de la connexion : il se connecte à lahsab, reçoit les events de votre marchand en temps réel, et les re-POST sur votre serveur local, signés exactement comme en production. Votre code de vérification de signature est exercé à l’identique, avec le même secret whsec_ que celui de votre environnement.

Écouter

Exporter la clé sandbox (visible dans Développeurs) :
```
export LAHSAB_API_KEY=lsk_sandbox_…
```
Lancer l’écouteur vers votre endpoint local :
```
lahsab listen --forward-to http://localhost:3000/webhooks/lahsab
```
Déclencher un event, depuis votre intégration, le dashboard, ou lahsab trigger :
```
lahsab trigger invoice.paid
```

Le CLI affiche chaque event reçu, le code de réponse de votre endpoint et la latence :

lahsab listen
  API      http://localhost:3100
  Forward  http://localhost:3000/webhooks/lahsab

17:42:03 Connecté : Ma Boutique (sandbox)
17:42:03 Signature avec le secret whsec_4f2…
17:42:03 En attente d'events… (Ctrl+C pour quitter)
17:42:19 invoice.paid [a1b2c3…] → 200 (34 ms)

Au démarrage, l’écouteur affiche le secret de signature utilisé : c’est le whsec_ de votre environnement sandbox (créé automatiquement s’il n’existait pas encore). Mettez-le dans le .env de votre serveur local : la vérification de signature fonctionne alors sans aucune adaptation entre le développement et la production.

Filtrer les types reçus :

lahsab listen \
  --forward-to http://localhost:3000/webhooks/lahsab \
  --events invoice.paid,payment.confirmed

Déclencher des events

lahsab trigger fabrique un scénario complet côté sandbox, fixtures comprises, et déclenche l’event associé, sans quitter le terminal :

Scénario	Ce qui se passe
`payment.intent_created`	Crée un intent
`payment.proof_submitted`	Intent + preuve synthétique
`payment.proof_validated`	Intent + preuve jugée cohérente, paiement non confirmé
`payment.confirmed`	Intent + preuve + confirmation
`payment.rejected`	Intent + preuve + rejet
`payment.expired`	Intent + expiration
`invoice.paid`	Produit + tarif + client + abonnement + facture payée
`billing.tick`	Force une exécution de l’horloge de facturation

Sous le capot

L’écouteur consomme un flux SSE authentifié par clé API, observable au curl :

curl -N http://localhost:3100/webhooks/listen \
  -H "x-api-key: lsk_sandbox_CLE" \
  -H "accept: text/event-stream"

Trois types de messages : ready (marchand, environnement, secret de signature), event (id, type, createdAt et body, le corps JSON exact qui est re-signé et forwardé), ping (keep-alive). À la reconnexion, le CLI transmet le dernier id reçu (Last-Event-ID) et le serveur rejoue les events manqués.

Les events existent indépendamment de la livraison : ils sont émis et persistés même sans URL d’endpoint configurée. Un endpoint configuré continue de recevoir ses livraisons normalement pendant qu’un écouteur tourne : les deux voies coexistent.