Webhooks — API publique Pesia v1

Les webhooks Pesia permettent à votre système de recevoir des notifications push dès qu'un événement métier survient (contrat, DPAE, fiche de paie, DSN, etc.).

Vous créez une ou plusieurs subscriptions, chacune indiquant une URL de réception et les types d'événements souhaités. Pesia signe chaque livraison avec HMAC SHA-256 afin que vous puissiez authentifier l'origine du message. Vous pouvez ainsi router différentes familles d'événements vers différents endpoints — voir Router vos events vers plusieurs endpoints.

Les abonnements et leurs livraisons sont isolés par organisation et environnement. Utilisez des identifiants sandbox avec X-Pesia-Env: sandbox pour vos tests, et des identifiants production avec X-Pesia-Env: production pour les dépôts réels.

Prérequis

Scope requis : webhooks:manage (voir Scopes).

Gérer vos abonnements

Le CRUD complet est disponible sous /partner/v1/webhooks/subscriptions. Vous pouvez enregistrer plusieurs abonnements — chacun avec sa propre URL, son sous-ensemble d'événements et son propre secret de signature.

Créer un abonnement

curl -X POST https://api.pesia.fr/partner/v1/webhooks/subscriptions \
  -H "Authorization: Bearer <token>" \
  -H "X-Pesia-Env: production" \
  -H "Idempotency-Key: 7c1d2e3f-4a5b-4c6d-8e9f-0a1b2c3d4e5f" \
  -H "Content-Type: application/json" \
  -d '{"endpointUrl": "https://webhooks.example.com/pesia", "eventTypes": ["dpae.declared", "dpae.acknowledged", "dpae.rejected"]}'

La réponse 201 contient le hmacSecret — retourné une seule fois, stockez-le immédiatement (il n'est jamais ré-exposé). Chaque abonnement a son propre secret. Le rejeu idempotent de cette création ne restitue pas le secret. En cas de perte, retrouvez l'abonnement par GET, puis supprimez-le en trois étapes (voir Supprimer un abonnement). Créez ensuite un nouvel abonnement avec une nouvelle Idempotency-Key. Un événement publié entre la désactivation et la nouvelle création ne vous est jamais livré.

Lister, modifier, supprimer

# Lister vos abonnements (paginé)
curl "https://api.pesia.fr/partner/v1/webhooks/subscriptions" \
  -H "Authorization: Bearer <token>" -H "X-Pesia-Env: production"

# Modifier les eventTypes ou (dés)activer un abonnement
curl -X PATCH https://api.pesia.fr/partner/v1/webhooks/subscriptions/8b2c6d10-4f7a-4b3e-91ac-2d5f8a6c0e49 \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production" \
  -d '{"eventTypes": ["dpae.declared", "dpae.acknowledged"], "active": true}'

PATCH modifie seulement eventTypes et active. Pour changer l'URL, créez d'abord le nouvel abonnement, puis supprimez l'ancien (voir Supprimer un abonnement). Idempotency-Key est requis pour POST, PATCH et DELETE.

Chaque abonnement porte lastDeliveryAt et lastFailureAt : l'instant de la dernière tentative réussie et celui de la dernière tentative en échec d'un événement du catalogue, ou null si aucune tentative n'est enregistrée. Un événement de test ne les change pas.

Supprimer un abonnement

Pesia refuse de supprimer un abonnement qui a encore des livraisons, quel que soit leur statut. Supprimez-le en trois étapes. Utilisez une nouvelle Idempotency-Key à chaque appel : après un succès, la même clé renvoie la première réponse et ne supprime rien.

# 1. Désactiver l'abonnement : Pesia ne démarre plus aucune tentative
curl -X PATCH https://api.pesia.fr/partner/v1/webhooks/subscriptions/8b2c6d10-4f7a-4b3e-91ac-2d5f8a6c0e49 \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production" \
  -d '{"active": false}'

# 2. Supprimer toutes ses livraisons
curl -X DELETE https://api.pesia.fr/partner/v1/webhooks/subscriptions/8b2c6d10-4f7a-4b3e-91ac-2d5f8a6c0e49/deliveries \
  -H "Authorization: Bearer <token>" \
  -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production"

# 3. Supprimer l'abonnement
curl -X DELETE https://api.pesia.fr/partner/v1/webhooks/subscriptions/8b2c6d10-4f7a-4b3e-91ac-2d5f8a6c0e49 \
  -H "Authorization: Bearer <token>" \
  -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production"

L'étape 2 répond 200 et donne le nombre de livraisons supprimées :

{
  "success": true,
  "data": { "id": "8b2c6d10-4f7a-4b3e-91ac-2d5f8a6c0e49", "deletedCount": 12 },
  "timestamp": "2026-10-12T09:12:44.318Z"
}

L'étape 2 supprime aussi les livraisons qui n'ont pas encore réussi : en attente, en nouvelle tentative ou en échec définitif. Leurs événements ne vous sont jamais livrés.

Une livraison peut être créée entre les étapes 2 et 3. L'étape 3 répond alors 409 webhook_subscription_has_deliveries, avec le champ deliveryCount. Refaites l'étape 2, puis l'étape 3.

L'étape 2 fonctionne aussi sur un abonnement actif. Désactivez-le d'abord : un abonnement actif peut recevoir une nouvelle livraison à tout moment.

Désactiver un abonnement

Un PATCH avec {"active": false} désactive un abonnement. Pesia ne démarre alors plus aucune tentative. Une tentative déjà en cours (10 secondes au plus) peut encore arriver.

Un événement publié pendant la désactivation ne crée aucune livraison. Il ne vous est jamais livré, même après la réactivation.
Les livraisons déjà créées qui attendent une tentative restent en attente. Elles ne consomment aucune tentative. Elles repartent quand vous réactivez l'abonnement ({"active": true}).
Une livraison qui repart peut arriver en double ou après des événements plus récents. Dédupliquez sur eventId et ne comptez pas sur l'ordre (voir Doublons, rejeux et ordre de livraison).

Destination de livraison

L'URL doit utiliser HTTPS en production comme en sandbox.
Elle doit être accessible publiquement, sans identifiant ni mot de passe dans l'URL.
Les destinations locales, privées et réservées sont refusées. Cette vérification porte aussi sur les adresses obtenues par résolution DNS lors de la connexion.
Les redirections HTTP ne sont pas suivies. Configurez directement l'URL HTTPS finale.
Une URL enregistrée peut ensuite échouer à la livraison si sa résolution DNS change ou si elle ne respecte plus ces conditions.

Limites

20 abonnements actifs maximum par organisation et environnement. Au-delà, la création et la réactivation (PATCH avec "active": true) renvoient 422 (webhook_subscription_limit_reached) — supprimez ou désactivez un abonnement d'abord.
Une même URL ne peut être enregistrée qu'une fois par organisation et environnement, même pour un abonnement désactivé (un doublon renvoie 409, webhook_subscription_duplicate). Pour deux familles d'événements distinctes, utilisez donc deux URLs différentes.

Headers de livraison

Chaque requête HTTP envoyée par Pesia vers votre endpoint inclut les cinq headers suivants :

Header	Type	Description
`X-Pesia-Event`	string	Type d'événement (ex. `contract.created`)
`X-Pesia-Event-Id`	UUID	Identifiant unique de l'occurrence (stable — même pour une re-livraison)
`X-Pesia-Timestamp`	int	Horodatage Unix en secondes
`X-Pesia-Signature`	string	Signature HMAC — format `t=<ts>,v1=<hex>` (voir ci-dessous)
`X-Pesia-Env`	string	Environnement source : `production` ou `sandbox`

Schéma de signature HMAC

Construction

La signature est un HMAC SHA-256 calculé sur la concaténation horodatage + corps :

payload_signé   = "<timestamp>.<corps_json_brut>"
signature_hex   = HMAC-SHA256(secret, payload_signé).hexdigest()
header          = "t=<timestamp>,v1=<signature_hex>"

<timestamp> : valeur entière de X-Pesia-Timestamp (secondes Unix).
<corps_json_brut> : corps de la requête tel qu'il arrive sur le fil — avant tout décodage.
<secret> : le hmacSecret retourné en one-shot lors de la création de la subscription (POST /partner/v1/webhooks/subscriptions). Il n'est jamais ré-exposé via l'API après cette réponse initiale.

Exemple de vecteur de vérification

secret    = "whsec_test_secret_example"
timestamp = 1748865600          # 2025-06-02T12:00:00Z
body      = '{"eventType":"contract.created","eventId":"evt-001"}'

payload_signé = "1748865600.{\"eventType\":\"contract.created\",\"eventId\":\"evt-001\"}"
signature_hex = hmac_sha256(secret, payload_signé)
header        = "t=1748865600,v1=<signature_hex>"

Vérification côté partenaire

Recette de vérification recommandée (exemple shell avec openssl) :

SECRET="whsec_votre_secret"

# X_PESIA_SIGNATURE = en-tête reçu, ex: "t=1748865600,v1=<hex>"
TS="${X_PESIA_SIGNATURE#t=}"; TS="${TS%%,*}"        # extrait le timestamp
RECU="${X_PESIA_SIGNATURE##*v1=}"                   # extrait la signature reçue

# 1. Fenêtre anti-replay ±5 min (300 s)
NOW="$(date +%s)"
if [ "$(( NOW - TS ))" -gt 300 ] || [ "$(( TS - NOW ))" -gt 300 ]; then
  echo "Rejeté : horodatage hors fenêtre"; exit 1
fi

# 2. Recalculer le HMAC-SHA256 sur "<timestamp>.<corps_brut>"
ATTENDU="$(printf '%s.%s' "$TS" "$BODY_RAW" \
  | openssl dgst -sha256 -hmac "$SECRET" -hex | sed 's/^.*= //')"

# 3. Comparer (préférez une comparaison constant-time dans votre langage applicatif)
[ "$ATTENDU" = "$RECU" ] && echo "Signature valide" || echo "Signature invalide"

Doublons, rejeux et ordre de livraison

La livraison est au moins une fois : votre endpoint peut recevoir le même événement plusieurs fois, notamment si sa réponse 2xx n'est pas reçue par Pesia. Dédupliquez les traitements avec eventId (ou le couple abonnement + eventId si vous traitez chaque abonnement séparément). Conservez cette trace selon la durée de vie de votre traitement métier ; un rejeu demandé à Pesia peut survenir après 24 heures.

Le corps de l'événement et occurredAt restent stables. X-Pesia-Timestamp et la signature sont recalculés à chaque tentative : appliquez la fenêtre de 5 minutes au timestamp de livraison, pas à occurredAt. Le timestamp de la signature doit correspondre au header X-Pesia-Timestamp. Vérifiez la signature avant tout traitement et utilisez une comparaison à temps constant dans votre application. Le shell ci-dessus illustre seulement le calcul.

Les livraisons ne garantissent pas l'ordre des événements. Pour une DPAE, consultez le statut courant via GET en cas de doute. Un ancien événement peut être livré après un verdict plus récent. Enregistrez le message de façon durable avant de répondre 2xx, puis traitez-le.

Catalogue des événements v1

Type d'événement	Description
`contract.created`	Un nouveau contrat de mission a été créé pour un intérimaire.
`contract.updated`	Un contrat existant a été modifié (dates, taux, poste, etc.).
`dpae.declared`	Certificat CCO reçu, texte dans `conformityCertificate`. Un CCO tardif préserve `ACK`.
`dpae.corrected`	Nouvelle version corrigée créée par Pesia ; aucune acceptation URSSAF promise.
`dpae.acknowledged`	AR individuel positif ; statut `ACK`, `arReceivedAt` et `rDossier`.
`dpae.identity_checked`	BIS reçu ; `identityResult` distinct du statut DPAE. Aucune donnée nominative.
`dpae.rejected`	Le dépôt de la DPAE s'est terminé en échec — rejet URSSAF ou échec technique (voir champ `status`). Émis en production et en sandbox.
`payroll.payslip.published`	Une fiche de paie a été émise et mise à disposition de l'intérimaire.
`dsn.declared`	Une DSN (Déclaration Sociale Nominative) mensuelle a été transmise.
`partner_api.version_deprecation`	La version v1 de l'API entrera en fin de vie dans ≥ 6 mois (voir Versioning).

La liste est exhaustive pour v1. De nouveaux types pourront être ajoutés de façon additive dans v1 sans breaking change (voir Stabilité du contrat).

L'événement webhook.test sert aux tests et reste hors de cette liste : voir Événement de test.

Corps de l'événement

Le corps JSON de chaque livraison est self-describing : il porte le type d'événement dans le champ eventType (identique au header X-Pesia-Event). Vous pouvez donc router sur le seul corps (switch (body.eventType)), sans dépendre des headers. Champs communs à tous les événements :

Champ	Type	Description
`eventType`	string	Type d'événement (ex. `dpae.acknowledged`) — clé de routage
`eventId`	UUID	Identifiant unique de l'occurrence (= `X-Pesia-Event-Id`, stable entre re-livraisons)
`occurredAt`	string	Horodatage ISO 8601 de l'événement métier
`tenantId`	string	Identifiant de périmètre Pesia, à traiter comme une valeur opaque.
`organizationId`	string	Organisation à l'origine de l'événement
`env`	string	`production` ou `sandbox`

Les champs spécifiques suivent selon le type (voir exemples ci-dessous).

Résultat BIS et lecture des corrections

dpae.identity_checked indique qu'un BIS est disponible. L'enregistrement DPAE et l'identité restent deux suivis indépendants. Un BIS NOT_IDENTIFIED ne révoque pas un AR positif. N'attendez pas cet événement pour considérer une DPAE avec AR positif comme enregistrée. Son absence ne prouve pas que l'identité a été vérifiée.

{
  "eventType": "dpae.identity_checked",
  "eventId": "c4a81208-3ab7-52e6-8b1a-b8c08c52ce03",
  "occurredAt": "2026-07-12T04:10:03Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "production",
  "dpaeId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d37",
  "agencySiret": "83123456700045",
  "contractExternalId": "CTT-2026-078451",
  "identityResult": "MODIFIED"
}

Le webhook ne contient aucune correction nominative. Lisez identity.corrections dans GET /partner/v1/dpae/submissions/{dpaeId}, avec votre jeton et le même X-Pesia-Env. Les valeurs possibles de identityResult sont IDENTIFIED, MODIFIED et NOT_IDENTIFIED. Un champ de correction nul signifie « aucune correction fournie ». Ne supprimez pas votre donnée. Dédupliquez chaque livraison par eventId. Le résultat et le contenu restent identiques lors d'un rejeu.

Ajoutez explicitement dpae.identity_checked aux abonnements existants après adaptation de votre récepteur. La liste des événements souscrits ne change pas automatiquement. Aucun ancien BIS ne déclenche de nouvelle notification rétroactive. dpae.corrected conserve son sens distinct : nouvelle version corrigée créée, sans preuve d'acceptation URSSAF. Consultez le parcours DPAE pour les anciennes données et les dates.

Événements DPAE

Abonnez-vous à dpae.declared, dpae.acknowledged, dpae.rejected et dpae.identity_checked. Un AR peut produire ACK avant le certificat de conformité : ne comptez pas sur deux événements de succès successifs. Un BIS produit dpae.identity_checked sans changer le statut DPAE. Le cycle DPAE précise ces cas.

Pesia conserve les événements DPAE à publier et reprend la publication après une indisponibilité temporaire. Un événement conserve son identifiant et son contenu lors des nouvelles tentatives. Cette reprise ne remplace pas votre traitement des doublons ni les limites des tentatives de livraison HTTP décrites ci-dessous.

dpae.declared — l'URSSAF a certifié la DPAE conforme :

{
  "eventType": "dpae.declared",
  "eventId": "3f8a1c7e-9d2b-4a6f-b5e0-7c4d8e1a3b96",
  "occurredAt": "2026-07-11T09:14:22Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "production",
  "dpaeId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d37",
  "agencySiret": "83123456700045",
  "contractExternalId": "CTT-2026-078451",
  "conformityCertificate": "CERTIFICAT-EXEMPLE"
}

dpae.acknowledged — AR individuel positif. Les références communes sont complétées par arReceivedAt et rDossier, sans certificat CCO. Les anciens messages peuvent omettre ces deux champs.

{
  "eventType": "dpae.acknowledged",
  "eventId": "b1e4a7d0-3c5f-4e2a-8d9b-6f1c0a7e5b42",
  "occurredAt": "2026-07-12T04:10:03Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "production",
  "dpaeId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d37",
  "agencySiret": "83123456700045",
  "contractExternalId": "CTT-2026-078451",
  "arReceivedAt": "2026-07-12T04:10:03Z",
  "rDossier": "DOSSIER-EXEMPLE"
}

dpae.rejected — le dépôt s'est terminé en échec. Même payload, complété d'un champ status qui distingue le verdict négatif (REJECTED) de l’échec d’envoi ou de traitement (FAILED, qui inclut les ARE). errorMessage contient le motif assaini :

{
  "eventType": "dpae.rejected",
  "eventId": "d9f2c5b8-1a4e-4f7c-a3d6-8b0e2c5f9a17",
  "occurredAt": "2026-07-12T04:10:03Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "production",
  "dpaeId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d37",
  "agencySiret": "83123456700045",
  "contractExternalId": "CTT-2026-078451",
  "status": "REJECTED",
  "errorMessage": "Bilan d’anomalie bloquant (BAN): code URSSAF invalide"
}

dpaeId reprend le submissionId retourné lors du dépôt ; contractExternalId permet de corréler l'événement avec le contrat dans votre système. La livraison est at-least-once : dé-dupliquez sur eventId (identique à X-Pesia-Event-Id, stable entre re-livraisons).

Ces notifications ne portent ni NIR ni workerExternalId. errorMessage et conformityCertificate peuvent être absents ou null sur les événements historiques. Le motif du rejet reste identique lors des nouvelles tentatives de publication. FAILED ou REJECTED ne prouve pas à lui seul qu’un nouvel envoi est sûr. Conservez le lien contrat/salarié lors du POST.

Correction du staff

Ajoutez dpae.corrected à vos abonnements pour recevoir les nouvelles versions corrigées. L’événement ne contient ni l’identité du salarié, ni les snapshots, ni le motif interne. Dédupliquez sur eventId. Lisez la nouvelle soumission avec GET.

{
  "eventType": "dpae.corrected",
  "eventId": "ba93d019-0e78-47c2-8d6b-25f8e909c38e",
  "occurredAt": "2026-09-12T10:00:00Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "sandbox",
  "dpaeId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d38",
  "sourceSubmissionId": "8f2d4c1a-5b3e-4f7a-9c2d-1e6b8a4f0d37",
  "agencySiret": "83123456700045",
  "contractExternalId": "CTT-2026-078451"
}

Événement de test

Pesia peut envoyer un événement webhook.test à un abonnement actif. Il vous permet de vérifier votre endpoint : réception, signature et réponse. Tout abonnement actif peut le recevoir, quels que soient ses eventTypes.

Cet événement est hors du catalogue : aucun abonnement ne peut le demander. Un POST ou un PATCH d'abonnement dont eventTypes le cite reçoit 400.

Contactez votre interlocuteur Pesia (partenaires@pesia.fr) pour recevoir un événement de test.

Le corps porte eventType et les champs communs du tableau « Corps de l'événement ». Il ne porte aucun champ propre à ce type :

{
  "eventType": "webhook.test",
  "eventId": "5f0c2a9e-7b1d-4c3e-8a6f-2d9b4e1c7a30",
  "occurredAt": "2026-09-12T10:00:00Z",
  "tenantId": "01a08af4-d5c0-735f-bcd5-2e17f00b873d",
  "organizationId": "01a08af4-d5f8-70bb-b8b9-df37692cbd9a",
  "env": "sandbox"
}

occurredAt est l'instant de la demande de test. eventId est égal au header X-Pesia-Event-Id.

La livraison porte les cinq headers de livraison, avec X-Pesia-Event: webhook.test. Elle porte la même signature HMAC que tout événement, calculée avec le secret de l'abonnement : vérifiez-la de la même façon.

Répondez 2xx et ne déclenchez aucun traitement métier. Une réponse hors 2xx suit la politique de retry.

Un événement de test ne change ni lastDeliveryAt ni lastFailureAt.

Router vos events vers plusieurs endpoints

Deux stratégies, au choix (ou combinées) :

Stratégie A — un seul endpoint, routage sur le corps. Vous abonnez une URL à tous les événements voulus et vous aiguillez côté application sur le champ eventType du corps (switch (body.eventType) { case "dpae.declared": … case "dpae.acknowledged": … }). Le plus simple à sécuriser : un seul endpoint, un seul secret.

Stratégie B — plusieurs endpoints, un par famille d'événements. Vous créez plusieurs abonnements, chacun avec une URL et un sous-ensemble d'eventTypes distinct. Pesia livre chaque événement uniquement aux abonnements dont les eventTypes le contiennent — idéal pour aiguiller vers des systèmes ou équipes différents (ex. un service qui traite les DPAE, un autre la DSN). Chaque endpoint reçoit son propre secret de signature.

# Endpoint dédié aux événements DPAE
curl -X POST https://api.pesia.fr/partner/v1/webhooks/subscriptions \
  -H "Authorization: Bearer <token>" -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production" -H "Content-Type: application/json" \
  -d '{"endpointUrl": "https://webhooks.example.com/pesia/dpae", "eventTypes": ["dpae.declared", "dpae.acknowledged", "dpae.rejected"]}'

# Endpoint dédié aux événements DSN
curl -X POST https://api.pesia.fr/partner/v1/webhooks/subscriptions \
  -H "Authorization: Bearer <token>" -H "Idempotency-Key: $(uuidgen)" -H "X-Pesia-Env: production" -H "Content-Type: application/json" \
  -d '{"endpointUrl": "https://webhooks.example.com/pesia/dsn", "eventTypes": ["dsn.declared"]}'

Ici, une DPAE acquittée n'arrive que sur /pesia/dpae, une DSN déclarée que sur /pesia/dsn.

Chevauchement : si deux abonnements souscrivent au même eventType, les deux le reçoivent (chacun signé avec son propre secret). Il n'y a pas d'exclusivité — c'est voulu (utile pour un endpoint de secours ou un consommateur d'audit).

Sécurisation de votre endpoint

Vérifiez toujours la signature avant de traiter le payload.
Répondez 2xx rapidement (< 5s) — Pesia réessaie sur timeout ou réponse hors 2xx.
Idempotence — utilisez X-Pesia-Event-Id comme clé de dé-duplication.
HTTPS public obligatoire dans les deux environnements, sans redirection.
Environnement — vérifiez que X-Pesia-Env et env correspondent à votre abonnement.

Politique de retry

8 tentatives, avec un backoff exponentiel : base 30 s, doublée à chaque tentative. Le délai le plus long est donc de 32 min, avant la 8ᵉ et dernière tentative. Une livraison qui échoue à chaque essai cumule environ 63 minutes 30 secondes de délais, plus la durée des tentatives et l'attente de traitement. Ce calcul n'est pas une garantie de délai. Chaque tentative HTTP dispose d'un timeout de 10 secondes. Toute réponse hors 2xx (y compris 3xx et 4xx), erreur réseau ou refus de destination compte comme un échec.

Tentative	Délai avant retry
1	Immédiat
2	30 s
3	1 min
4	2 min
5	4 min
6	8 min
7	16 min
8 (dernier)	32 min

Après 8 échecs consécutifs, la livraison est marquée en échec définitif et n'est plus re-tentée automatiquement. Contactez votre interlocuteur Pesia pour investiguer ou demander un nouveau rejeu.

Les tentatives d'un abonnement désactivé sont suspendues jusqu'à sa réactivation (voir Désactiver un abonnement).

Voir aussi

Idempotence — header Idempotency-Key obligatoire sur POST/PATCH/DELETE webhooks
Scopes — scope webhooks:manage
webhook_subscription_has_deliveries — suppression refusée tant que l'abonnement a des livraisons
DPAE — événements dpae.declared, dpae.acknowledged et dpae.rejected
Versioning — événement partner_api.version_deprecation

Prérequis​

Gérer vos abonnements​

Créer un abonnement​

Lister, modifier, supprimer​

Supprimer un abonnement​

Désactiver un abonnement​

Destination de livraison​

Limites​

Headers de livraison​

Schéma de signature HMAC​

Construction​

Exemple de vecteur de vérification​

Vérification côté partenaire​

Doublons, rejeux et ordre de livraison​

Catalogue des événements v1​

Corps de l'événement​

Résultat BIS et lecture des corrections​

Événements DPAE​

Correction du staff​

Événement de test​

Router vos events vers plusieurs endpoints​

Sécurisation de votre endpoint​

Politique de retry​

Voir aussi​