Webhooks

Les webhooks vous permettent de recevoir des notifications en temps reel lorsque des evenements se produisent dans votre compte LabelGrid. Utilisez les webhooks pour automatiser des workflows et vous integrer a des systemes externes.

Note

Les webhooks necessitent que l’acces API soit active sur votre compte. Contactez le support si vous avez besoin d’activer cette fonctionnalite.

Pour les developpeurs : Vous pouvez egalement gerer les webhooks de maniere programmatique via l’API. Consultez la documentation de l’API LabelGrid pour les endpoints et exemples.

Comment fonctionnent les webhooks

1. Vous configurez un webhook - Specifiez une URL et les evenements a ecouter
2. Un evenement se produit - Par exemple, une sortie est livree a un store
3. LabelGrid envoie une requete POST - Votre serveur recoit les donnees de l’evenement
4. Votre systeme les traite - Automatisez des workflows en fonction de l’evenement

---

Acceder aux webhooks

1. Cliquez sur votre icone de profil en haut a droite
2. Selectionnez Webhooks dans le menu deroulant

---

Creer un webhook

1. Cliquez sur Create Webhook
2. Saisissez un Name pour identifier ce webhook
3. Saisissez l’URL ou vous souhaitez recevoir les notifications
4. Selectionnez les Events qui doivent declencher ce webhook
5. Cliquez sur Create

Secret du webhook

Lorsque vous creez un webhook, vous recevez une cle secrete. Utilisez-la pour verifier que les requetes entrantes proviennent bien de LabelGrid :

• Stockez le secret de maniere securisee
• Verifiez la signature des requetes entrantes
• En cas de compromission, regenerez le secret

---

Evenements disponibles

Configurez votre webhook pour ecouter ces evenements. L’identifiant d’evenement est la valeur que vous verrez dans la propriete event du payload et dans le header X-Webhook-Event :

Identifiant d’evenement	Description
delivery.completed	Declenche lorsqu’une sortie est livree avec succes a un store
delivery.failed	Declenche lorsque la livraison a un store echoue
takedown.completed	Declenche lorsqu’une demande de retrait est terminee
release.review.status_changed	Declenche lorsque le statut de revision d’une sortie change
release.preflight.report_ready	Declenche lorsque le rapport Preflight QC d’une sortie en attente est pret a etre recupere
stream_radar.flag_created	Declenche lorsqu’un signalement Stream Radar est cree, ou qu’un signalement resolu rouvre sur une nouvelle detection
stream_radar.flag_resolved	Declenche lorsqu’un signalement Stream Radar se resout parce que les detections ont cesse
release.distributed	Declenche lorsqu’une sortie est distribuee
payment.statement_ready	Declenche lorsqu’un releve de paiement est pret a etre consulte
transcode.completed	Declenche lorsque le transcodage audio d’une piste se termine avec succes
transcode.failed	Declenche lorsque le transcodage d’une piste echoue ou se termine de facon incomplete
distribution.outlet.status_changed	Declenche a chaque transition de statut de distribution par outlet

Vous pouvez selectionner plusieurs evenements pour un seul webhook, ou creer des webhooks separes pour differents types d’evenements.

Vous pouvez aussi lire cette liste de maniere programmatique : GET /api/public/webhooks/event-types renvoie chaque evenement accompagne d’un schema data decrivant les cles et les types de son payload, afin que les consommateurs a schema strict puissent elargir leur validation entrante a l’avance.

---

Gerer les webhooks

Consulter vos webhooks

La liste des webhooks affiche :

Colonne	Description
Name	Le nom que vous avez attribue au webhook
URL	Ou les notifications sont envoyees
Events	Nombre d’evenements configures
Status	Active ou Inactive
Success / Fail	Nombre de livraisons reussies et echouees
Last Triggered	Derniere activation du webhook

Modifier un webhook

1. Cliquez sur l’action Edit sur la ligne du webhook
2. Modifiez le nom, l’URL ou les evenements
3. Cliquez sur Save

Activer / Desactiver

Basculez le statut actif d’un webhook sans le supprimer :

• Active - Le webhook recevra les notifications
• Inactive - Le webhook est en pause, aucune notification envoyee

Supprimer un webhook

1. Cliquez sur l’action Delete sur la ligne du webhook
2. Confirmez la suppression

Danger

Les webhooks supprimes ne peuvent pas etre recuperes.

---

Tester les webhooks

Avant de dependre d’un webhook en production, testez-le :

1. Cliquez sur l’action Test sur votre webhook
2. LabelGrid envoie un payload de test a votre URL
3. Verifiez que votre endpoint a bien recu et traite correctement

Note

Le payload de test ne correspond pas a la forme des evenements reels. Le champ event de son enveloppe est "test" et l’objet data contient { "test": true, "message": "...", "timestamp": "..." }. Utilisez-le pour verifier la connectivite et la gestion de la signature, mais ecrivez vos gestionnaires d’evenements en fonction des payloads d’evenements reels documentes dans Payloads des evenements.

---

Consulter les journaux des webhooks

Surveillez l’activite des webhooks et depannez les problemes :

1. Cliquez sur l’action View Logs sur un webhook
2. Consultez l’historique de toutes les livraisons du webhook

Details des journaux

Chaque entree de journal affiche :

Champ	Description
Event Type	L’evenement qui a declenche cette livraison
Response Status	Code de statut HTTP de votre serveur
Duration	Duree de la requete
Attempt	Numero de la tentative de renvoi
Timestamp	Date et heure de la livraison

---

Format du payload webhook

Lorsqu’un evenement se produit, LabelGrid envoie une requete POST a votre URL avec un payload JSON :

{
  "event": "delivery.completed",
  "timestamp": "2026-05-05T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    // Donnees specifiques a l'evenement
  }
}

Le champ timestamp utilise le format ISO 8601. webhook_id est l’ID de votre webhook configure (il correspond au header X-Webhook-Id).

---

Payloads des evenements

La structure de l’objet data depend du type d’event. Tous les types de champs ci-dessous sont des types JSON tels que serialises dans le payload.

delivery.completed

Declenche une fois par outlet lorsqu’une livraison de sortie atteint un etat de succes terminal.

{
  "event": "delivery.completed",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "distro_queue_id": 456,
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "outlet_id": 12,
    "outlet_name": "Spotify",
    "status": "complete"
  }
}

Champ	Type	Description
distro_queue_id	integer	ID interne de la file pour cette tentative de livraison
release_id	integer	La sortie qui a ete livree
label_id	integer	Le label proprietaire de la sortie, pour router l’evenement sans requete supplementaire
release_cat	string | null	Votre reference de catalogue de sortie
outlet_id	integer | null	L’ID de l’outlet de destination
outlet_name	string | null	Nom lisible de l’outlet (par exemple, "Spotify")
status	string	Toujours "complete" pour cet evenement

delivery.failed

Declenche une fois par outlet lorsqu’une livraison de sortie atteint un etat d’echec terminal. Meme payload que delivery.completed plus un champ message.

{
  "event": "delivery.failed",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "distro_queue_id": 456,
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "outlet_id": 12,
    "outlet_name": "Spotify",
    "status": "error",
    "message": "Outlet rejected the delivery: missing ISRC."
  }
}

Champ	Type	Description
status	string	L’un de error, fault, rejected, batch_exception
message	string | null	Raison de l’echec depuis l’outlet ou le pipeline de distribution

Note

Les echecs d’infrastructure interne (par exemple, les echecs de copie de fichiers audio vers nos serveurs de livraison) ne declenchent pas delivery.failed. Seuls les echecs cote DSP et au niveau du pipeline declenchent cet evenement.

takedown.completed

Declenche une fois par outlet lorsqu’une demande de retrait reussit. Meme forme que delivery.completed plus un indicateur takedown: true.

{
  "event": "takedown.completed",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "distro_queue_id": 456,
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "outlet_id": 12,
    "outlet_name": "Spotify",
    "status": "complete",
    "takedown": true
  }
}

release.distributed

Declenche une fois par sortie lorsque la sortie passe a l’etat de livraison distributed. Ne se declenche que sur la transition vers distributed, pas sur les enregistrements suivants pendant que la sortie est deja distribuee.

{
  "event": "release.distributed",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "release_title": "Summer EP",
    "delivery_status": "distributed"
  }
}

release.review.status_changed

Declenche chaque fois qu’une sortie passe d’un etat de revision a un autre.

{
  "event": "release.review.status_changed",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "release_title": "Summer EP",
    "previous_status": "to_review",
    "new_status": "approved"
  }
}

Champ	Type	Description
previous_status	string	Statut precedent. L’un de draft, to_review, approved, rejected, require_changes, audit
new_status	string	Nouveau statut. Meme ensemble de valeurs
review_issues	array (optionnel)	Present uniquement sur les transitions vers require_changes et rejected : les problemes qui demandent votre attention. La cle est omise sur toute autre transition, ne considerez donc pas qu’elle est toujours presente

Note

Le statut audit indique une nouvelle execution declenchee par un operateur des verifications de problemes sur une sortie deja approuvee. Il n’est jamais declenche par vos propres actions, et une sortie en audit reste en ligne sur les DSP pendant que la nouvelle verification s’execute.

release.preflight.report_ready

Declenche lorsque le rapport de qualite Preflight QC d’une sortie en mise en attente avant revision est pret a etre recupere. Necessite l’option Preflight QC sur votre compte.

{
  "event": "release.preflight.report_ready",
  "timestamp": "2026-07-07T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "release_title": "Summer EP",
    "generated_at": "2026-07-07T09:58:12+00:00",
    "profile": { "name": "quality_report", "version": 2 },
    "counts": { "blocking": 1, "informational": 2, "requires_feedback": 1 }
  }
}

Champ	Type	Description
release_id	integer	La sortie a laquelle appartient le rapport
label_id	integer	Le label proprietaire de la sortie
release_cat	string | null	Votre reference de catalogue de sortie
release_title	string | null	Le titre de la sortie
generated_at	string	Quand les verifications se sont terminees (ISO 8601). Correspond au report.generated_at de l’endpoint du rapport de qualite
profile	object	Le profil de qualite selon lequel les decomptes ont ete calcules : {name, version}
counts	object	Uniquement des decomptes agreges : {blocking, informational, requires_feedback}. Le decompte requires_feedback recoupe les deux autres

Note

Le payload ne contient jamais les problemes eux-memes. A reception, recuperez le rapport complet depuis l’endpoint du rapport de qualite. Voir Preflight QC : utilisation de l’API.

stream_radar.flag_created

Declenche lorsqu’un signalement Stream Radar est cree, soit un signalement entierement nouveau, soit un signalement precedemment resolu qui rouvre sur une nouvelle detection. Necessite l’option Stream Radar sur votre compte. Le champ transition distingue les deux cas : published pour un nouveau signalement, reopened pour un signalement redevenu actif.

{
  "event": "stream_radar.flag_created",
  "timestamp": "2026-07-07T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "flag_id": 4501,
    "dsp": "spotify",
    "isrc": "USRC12345678",
    "release_id": 789,
    "track_id": 654,
    "severity": "high",
    "status": "active",
    "transition": "published",
    "first_detected_at": "2026-07-06T00:00:00+00:00",
    "last_detected_at": "2026-07-07T00:00:00+00:00",
    "estimated_affected_streams": 12500,
    "published_at": "2026-07-07T09:58:12+00:00",
    "resolved_at": null
  }
}

Champ	Type	Description
flag_id	integer	L’identifiant stable du signalement ; correspond a id sur les endpoints Stream Radar
dsp	string	La plateforme sur laquelle le motif a ete observe (p. ex. spotify)
isrc	string	L’ISRC de l’enregistrement concerne
release_id	integer	La sortie a laquelle appartient l’enregistrement
track_id	integer | null	La piste precise, lorsque l’ISRC correspond sans ambiguite a l’une de vos pistes
severity	string	low, medium ou high
status	string	active pour cet evenement
transition	string	published pour un nouveau signalement, reopened lorsqu’un signalement resolu est redevenu actif
first_detected_at	string | null	Quand le motif a ete observe pour la premiere fois pour cette piste et cette plateforme (ISO 8601)
last_detected_at	string | null	La detection la plus recente (ISO 8601)
estimated_affected_streams	integer | null	Une estimation du nombre d’ecoutes impliquees
published_at	string	Quand le signalement vous a ete remonte pour la premiere fois (ISO 8601)
resolved_at	string | null	null tant que le signalement est actif

stream_radar.flag_resolved

Declenche lorsqu’un signalement Stream Radar se resout parce que les detections ont cesse. Necessite l’option Stream Radar. Memes champs que stream_radar.flag_created (sans transition), avec status regle sur resolved et resolved_at renseigne.

{
  "event": "stream_radar.flag_resolved",
  "timestamp": "2026-07-14T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "flag_id": 4501,
    "dsp": "spotify",
    "isrc": "USRC12345678",
    "release_id": 789,
    "track_id": 654,
    "severity": "high",
    "status": "resolved",
    "first_detected_at": "2026-07-06T00:00:00+00:00",
    "last_detected_at": "2026-07-12T00:00:00+00:00",
    "estimated_affected_streams": 18700,
    "published_at": "2026-07-07T09:58:12+00:00",
    "resolved_at": "2026-07-14T09:55:03+00:00"
  }
}

Note

La livraison des webhooks Stream Radar se fait au mieux. Traitez les endpoints de signalements Stream Radar comme la source de verite et utilisez ces evenements comme une incitation a lire l’etat actuel. Voir Stream Radar : utiliser l’API.

payment.statement_ready

Declenche lorsqu’un releve de paiement est genere et pret a etre consulte.

{
  "event": "payment.statement_ready",
  "timestamp": "2026-05-18T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "payment_request_id": 1024,
    "invoice_number": "INV-2026-001",
    "period": "2026-04-30",
    "amount": 1234.56,
    "total_due_usd": 1234.56,
    "currency": "USD"
  }
}

Champ	Type	Description
payment_request_id	integer	ID interne de la demande de paiement
invoice_number	string	Reference de facture pour le releve
period	string | null	Date de fin de periode (date ISO 8601, YYYY-MM-DD)
amount	number	Montant du releve dans la devise currency
total_due_usd	number	Total du releve converti en USD
currency	string	Code de devise ISO 4217 (par defaut USD)

Note

payment.statement_ready a une portee au niveau du compte : il ne contient ni release_id ni label_id.

transcode.completed et transcode.failed

Declenche lorsque le transcodage audio d’une piste se termine. transcode.completed se declenche en cas de succes ; transcode.failed se declenche lorsque le transcodage echoue ou se termine de facon incomplete. Les deux partagent la meme forme de payload.

{
  "event": "transcode.completed",
  "timestamp": "2026-07-07T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "release_id": 789,
    "label_id": 321,
    "track_id": 654,
    "transcoder_queue_id": 987,
    "status": "complete",
    "status_message": "transcode_complete",
    "files": [
      { "asset_type_id": 2, "status": "complete" }
    ]
  }
}

Champ	Type	Description
release_id	integer	La sortie a laquelle appartient la piste
label_id	integer	Le label proprietaire de la sortie
track_id	integer	La piste qui a ete transcodee
transcoder_queue_id	integer	ID interne de la file de transcodage
status	string	Statut brut de la file : complete, error ou incomplete
status_message	string	Code de motif sur et enumere : transcode_complete, transcode_error ou transcode_incomplete
files	array	Detail par fichier pour la piste : {asset_type_id, status} par fichier transcode

distribution.outlet.status_changed

Declenche a chaque transition de statut de distribution par outlet (par exemple scheduled → transcoding → batched → complete), pas seulement les transitions terminales couvertes par delivery.completed, delivery.failed et takedown.completed. Cet evenement est bavard par nature : abonnez-vous a lui uniquement si vous voulez la progression complete par outlet.

{
  "event": "distribution.outlet.status_changed",
  "timestamp": "2026-07-07T10:00:00+00:00",
  "webhook_id": "123",
  "data": {
    "distro_queue_id": 456,
    "release_id": 789,
    "label_id": 321,
    "release_cat": "ABC123",
    "outlet_id": 12,
    "outlet_name": "Spotify",
    "previous_status": "transcoding",
    "status": "batched"
  }
}

Champ	Type	Description
distro_queue_id	integer	ID interne de la file pour cette livraison
release_id	integer	La sortie en cours de distribution
label_id	integer	Le label proprietaire de la sortie
release_cat	string | null	Votre reference de catalogue de sortie
outlet_id	integer | null	L’ID de l’outlet de destination
outlet_name	string | null	Nom lisible de l’outlet
previous_status	string | null	Le statut precedent ; null lorsque la ligne n’avait aucun statut precedent reconnu
status	string	Le nouveau statut

---

Verification des signatures webhook

Chaque livraison de webhook est signee afin que vous puissiez verifier qu’elle provient bien de LabelGrid. Verifiez toujours la signature avant de traiter l’evenement.

Headers de la requete

Chaque requete POST de webhook inclut ces headers :

Header	Description
X-Webhook-Signature	HMAC-SHA256 du corps brut de la requete, en hexadecimal minuscule, sans prefixe d’algorithme
X-Webhook-Timestamp	Horodatage ISO 8601 de la livraison (meme valeur que la propriete timestamp dans le corps)
X-Webhook-Event	Identifiant d’evenement (par exemple, delivery.completed)
X-Webhook-Id	L’ID du webhook recevant la livraison
User-Agent	LabelGrid-Webhooks/1.0
Content-Type	application/json

Algorithme

• Algorithme : HMAC-SHA256
• Encodage : Hexadecimal minuscule
• Prefixe : Aucun — la valeur est juste le digest hex, pas sha256=...
• Contenu signe : Le corps JSON brut complet de la requete (le corps inclut l’horodatage en tant que propriete, donc l’horodatage est signe implicitement)

Recette de verification

1. Lisez le corps brut de la requete avant tout parsing ou transformation JSON. Re-serialiser le JSON parse peut produire des octets differents et casser la signature.
2. Calculez HMAC-SHA256(corps_brut, votre_secret_webhook) et prenez le digest hexadecimal minuscule.
3. Comparez avec X-Webhook-Signature en utilisant une comparaison a temps constant.
4. (Recommande) Rejetez la requete si X-Webhook-Timestamp est plus ancien que votre fenetre de tolerance de rejeu — nous suggerons 5 minutes.

Exemple PHP

$rawBody = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '';
$timestamp = $_SERVER['HTTP_X_WEBHOOK_TIMESTAMP'] ?? '';

$expected = hash_hmac('sha256', $rawBody, $webhookSecret);

if (! hash_equals($expected, $signature)) {
    http_response_code(401);
    exit('Signature invalide');
}

// Rejeter les livraisons de plus de 5 minutes
if (abs(time() - strtotime($timestamp)) > 300) {
    http_response_code(401);
    exit('Livraison obsolete');
}

$payload = json_decode($rawBody, true);
// ... traiter l'evenement
http_response_code(200);

Exemple Node.js

const crypto = require('crypto');

// Express : capturer le corps brut AVANT tout middleware JSON
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const rawBody = req.body; // Buffer
  const signature = req.header('X-Webhook-Signature') || '';
  const timestamp = req.header('X-Webhook-Timestamp') || '';

  const expected = crypto
    .createHmac('sha256', webhookSecret)
    .update(rawBody)
    .digest('hex');

  const sigBuf = Buffer.from(signature, 'hex');
  const expBuf = Buffer.from(expected, 'hex');

  if (sigBuf.length !== expBuf.length || !crypto.timingSafeEqual(sigBuf, expBuf)) {
    return res.status(401).send('Signature invalide');
  }

  if (Math.abs(Date.now() - new Date(timestamp).getTime()) > 5 * 60 * 1000) {
    return res.status(401).send('Livraison obsolete');
  }

  const payload = JSON.parse(rawBody.toString('utf8'));
  // ... traiter l'evenement
  res.sendStatus(200);
});

Exemple Python

import hmac, hashlib
from datetime import datetime, timezone

raw_body = request.get_data()  # Flask : bytes, avant tout parsing JSON
signature = request.headers.get('X-Webhook-Signature', '')
timestamp = request.headers.get('X-Webhook-Timestamp', '')

expected = hmac.new(
    webhook_secret.encode('utf-8'),
    raw_body,
    hashlib.sha256
).hexdigest()

if not hmac.compare_digest(expected, signature):
    return ('Signature invalide', 401)

delivery_time = datetime.fromisoformat(timestamp.replace('Z', '+00:00'))
if abs((datetime.now(timezone.utc) - delivery_time).total_seconds()) > 300:
    return ('Livraison obsolete', 401)

return ('', 200)  # traiter l'evenement puis acquitter

Pieges courants

• Re-serialiser le corps avant de le hacher. Les frameworks qui parsent automatiquement le JSON (Express express.json(), le corps de requete par defaut de Laravel) perdent les octets originaux. Capturez d’abord le corps brut.
• Utiliser une comparaison qui n’est pas a temps constant (==, ===). Susceptible aux attaques temporelles — utilisez toujours hash_equals (PHP), crypto.timingSafeEqual (Node), hmac.compare_digest (Python), ou l’equivalent dans votre langage.
• S’attendre a un prefixe sha256=. La valeur du header est juste le digest hex sans prefixe.
• Omettre la verification de l’horodatage. Sans cela, une signature divulguee pourrait etre rejouee indefiniment.

---

Limites et fiabilite

Limites de requete

Limite	Valeur
Timeout de requete	10 secondes
Taille maximale du payload	64 Ko
Maximum de webhooks par utilisateur	10

Si votre endpoint ne repond pas dans les 10 secondes, la livraison est consideree comme un echec et renvoyee.

Calendrier de renvoi

Si votre endpoint retourne un statut non-2xx ou expire, LabelGrid renvoie avec un backoff exponentiel :

Tentative	Attente avant le renvoi
1 → 2	30 secondes
2 → 3	1 minute
3 → 4	2 minutes
4 → 5	4 minutes
5 → 6	8 minutes
6 → 7	16 minutes
7 → 8	32 minutes
8 → 9	64 minutes
9 → 10	128 minutes

Chaque intervalle inclut 0 a 30 secondes de jitter. Apres 10 tentatives (~4,5 heures de temps total ecoule), la livraison est journalisee comme definitivement echouee et n’est plus renvoyee.

Desactivation automatique

Si un webhook accumule 100 livraisons echouees cumulees, il est automatiquement desactive. Reactivez-le manuellement dans la liste des webhooks apres avoir corrige votre endpoint. La reactivation d’un webhook desactive remet son compteur d’echecs a zero.

Bonnes pratiques pour la fiabilite

• Retournez une reponse 2xx rapidement (en moins de 10 secondes)
• Traitez les donnees de maniere asynchrone apres avoir acquitte
• Verifiez la signature de chaque requete (voir Verification des signatures webhook)
• Surveillez votre compteur d’echecs dans la liste des webhooks
• Consultez les journaux de livraison lorsque vous enquetez sur des evenements manques

---

Cas d’utilisation

Notifications automatisees

• Envoyer des messages Slack lorsque les sorties sont en ligne
• Emailer votre equipe en cas d’echec de livraison
• Mettre a jour les tableaux de bord internes

Automatisation de workflow

• Declencher des campagnes marketing lorsque les sorties sont distribuees
• Mettre a jour votre site web lorsque du nouveau contenu est disponible
• Synchroniser le statut avec des outils de gestion de projet externes

Surveillance et alertes

• Obtenir des alertes instantanees en cas d’echec de livraison
• Suivre la progression de la distribution en temps reel
• Surveiller les changements de statut de revision

---

Depannage

Le webhook ne recoit pas d’evenements

1. Verifiez le statut - Le webhook est-il Active ?
2. Verifiez l’URL - L’endpoint est-il accessible depuis internet ?
3. Verifiez les evenements - Les bons evenements sont-ils selectionnes ?
4. Consultez les journaux - Des erreurs sont-elles enregistrees ?

Nombre d’echecs eleve

1. Verifiez votre endpoint - Retourne-t-il 200 OK ?
2. Verifiez le temps de reponse - Repond-il dans le delai imparti ?
3. Examinez les messages d’erreur - Qu’est-ce qui echoue ?
4. Testez manuellement - Envoyez un webhook de test

Regenerer le secret

Si votre secret webhook est compromis :

1. Cliquez sur Regenerate Secret dans les parametres du webhook
2. Mettez a jour votre application avec le nouveau secret
3. L’ancien secret cesse immediatement de fonctionner

---

Besoin d’aide ?

Si vous avez des questions sur les webhooks, contactez notre equipe support.