API
Intégrateur PagerDuty API, du signal à la bonne astreinte
Une alerte reçue ne prouve ni que le bon incident a été ouvert, ni que la bonne personne peut agir. Dawap construit l’intégration PagerDuty autour du service impacté, de la clé de déduplication, de la politique d’escalade, de la couverture d’astreinte et de la boucle avec le monitoring, l’ITSM et le runbook.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse courte
Une alerte PagerDuty vaut par la personne joignable et le cycle qu’elle ferme.
Dawap sépare l’ingestion Events API v2 des opérations REST, rattache chaque source au bon service, stabilise la dedup_key et vérifie schedules, règles d’escalade, transitions et webhooks V3. Aucun projet client public n’est présenté comme une intégration PagerDuty déjà livrée : les références plus bas prouvent seulement des pratiques adjacentes de supervision, d’alerting et de reprise.
- Choisir la bonne API et la bonne clé : routing key Events pour un service, clé REST bornée aux opérations nécessaires.
- Conserver une dedup_key déterministe et sensible à la casse pour regrouper trigger, acknowledge et resolve du même événement.
- Tester le chemin source–service–politique–schedule–personne, puis la boucle webhook–ITSM jusqu’au verdict final.
La personne avant le 202
Le routage est prouvé seulement quand quelqu’un peut réellement agir.
Cette carte suit un même incident depuis sa clé de déduplication jusqu’au répondant couvert, puis vérifie chaque transition avant de toucher l’ITSM.
Machine d’étatsIncident PD-8731
sans boucle- 00:00Triggerdedup_key conservéecreated
Le signal rejoint l’incident unique.
- 00:42AcknowledgeRépondant identifiéowned
L’escalade s’arrête, pas l’incident.
- 08:14ResolveÉtat fournisseur reluclosed
La cause et le ticket sont rapprochés.
- 08:16Webhook retardéTransition refuséeignored
L’ack ancien ne rouvre pas le cycle.
Signaux d’astreinte
Trois ruptures empêchent une alerte d’atteindre le bon répondant.
Le code 202 confirme une réception, jamais la déduplication, la couverture humaine ou la cohérence du statut ITSM.
01
Identité
La dedup_key change
Casse ou format divergent ouvre deux incidents pour le même symptôme.
02
Couverture
La politique ne joint personne
Schedule, restriction, override ou fuseau laissent un trou au moment critique.
03
Boucle
Les webhooks inversent le statut
Un acknowledged retardé écrase resolved et réactive le ticket externe.
Architecture PagerDuty API
Le routage se prouve du signal à la personne, pas au seul code 202
Events API, REST, services, politiques, schedules et webhooks n’ont pas le même rôle. Le connecteur fixe leur frontière, leurs identités et leurs autorités avant d’automatiser une réponse de production.
Events API et REST séparées
Events API v2 reçoit trigger, acknowledge et resolve avec la routing key d’une intégration liée à un service. REST utilise sa propre authentification pour lire ou administrer les objets permis. Une clé ne remplace pas l’autre.
Clés, tokens et droits bornés
La routing key reste propre au service de réception. Côté REST, clé générale en lecture seule, token utilisateur hérité de ses permissions ou token à scopes sont choisis selon le parcours ; secrets, rotation et révocation restent tracés hors du code.
dedup_key conservée sans transformation
La clé fournie au premier trigger est réutilisée à l’identique pour regrouper les alertes et viser le même incident. Casse, troncature ou recomposition implicite peuvent ouvrir un second incident au lieu de poursuivre le premier.
Chaîne service–politique–schedule
Le service pointe vers une politique d’escalade, dont les règles ciblent utilisateurs ou schedules. Chaque niveau, délai, restriction, override et fuseau est vérifié jusqu’à la personne réellement joignable.
Alerte et incident non confondus
Plusieurs alertes peuvent être regroupées sous un incident. Le connecteur conserve les identifiants fournisseur, la dedup_key et la référence interne ; le titre visible ne devient ni identité ni preuve de regroupement.
Webhook V3 vérifié puis relu
Le consommateur contrôle l’abonnement indiqué par x-webhook-subscription, vérifie x-pagerduty-signature sur le corps brut, journalise l’event ID et relit l’état courant avant une mutation irréversible.
Méthode
Prouver un cycle isolé avant d’ouvrir l’astreinte et le ticketing de production
Le pilote part d’un signal non critique connu. Il fixe service et dedup_key, vérifie la personne couverte, déroule trigger, répétition, acknowledge et resolve, puis rejoue les webhooks dans le désordre. Les mutations ITSM et l’astreinte réelle restent fermées tant que l’identité, la couverture ou la machine d’états peuvent mentir.
Qualifier la source
Signal, service et routing key sont liés explicitement.
Stabiliser l’identité
Une dedup_key exacte porte tout le cycle.
Prouver la couverture
Politique, schedule et personne sont vérifiés dans le temps.
Fermer sans boucle
État relu, webhook ordonné et autorité ITSM tranchent.
Premier lot PagerDuty
Prouver un cycle d’incident non critique sans toucher l’astreinte de production.
On isole un service, une intégration Events API v2 et une politique de test. Un même symptôme est déclenché plusieurs fois avec une dedup_key stable, acquitté puis résolu ; le webhook V3 est observé sans piloter encore le ticketing de production. Le lot reste bloqué si le service est ambigu, si la couverture ne peut pas être prouvée ou si les événements arrivent dans un ordre non maîtrisé.
Entrée : un signal non critique
Sortie : incident traçable
Suite : ITSM sous contrôle
Sorties concrètes
Matrice source × intégration × service × équipe × politique × schedule × environnement × responsable.
Contrat référence interne–dedup_key–incident ID–service–urgence–statut–ticket externe–dernier événement accepté.
Recette trigger répété, acknowledge, resolve, changement de casse, personne indisponible, webhook en retard, 401, 403 et 429.
Journal expurgé, requêtes corrélées, événements signés, timeline, destinataire réel, limite résiduelle et verdict du run.
Scénarios de recette, non résultats client
Trois contre-tests qui révèlent une intégration PagerDuty fragile
Ces scénarios décrivent les preuves exigées sur le pilote. Ils ne sont pas présentés comme des résultats client PagerDuty déjà obtenus par Dawap.
Le même symptôme ouvre deux incidents après un changement de format ou de casse
Le premier trigger utilise payments:prod:latency, puis une autre source envoie Payments:prod:latency ou recalcule la clé depuis un libellé. Le signal paraît identique à l’écran, mais PagerDuty ne poursuit pas le même groupe.
- Entrée
- Source, version du producteur, service, routing key, action, dedup_key brute, casse, longueur, incident ID, alert IDs, horodatage et référence interne.
- Sortie
- Schéma de clé versionné, fonction pure documentée, registre de corrélation, fixture commune aux producteurs et garde-fou qui bloque acknowledge ou resolve sans clé connue.
- Décision
- Ne jamais reconstruire la clé depuis un titre libre ; conserver la valeur émise au trigger et suspendre la mutation lorsque la corrélation est ambiguë.
Le service existe mais aucun répondant n’est couvert au moment du test
La politique cible un schedule dont la restriction ou le fuseau laisse un trou, tandis qu’un override attendu n’est pas actif. L’incident est créé correctement, mais la chaîne ne garantit pas qu’une personne puisse intervenir.
- Entrée
- Service, politique attachée, snapshot de politique sur incident ouvert, niveaux, délais, cibles, schedule, layers, restrictions, overrides, fuseaux, utilisateurs et règles de notification.
- Sortie
- Matrice de couverture, test temporel autour des changements de rotation, destinataire de secours, alerte sur trou et procédure d’escalade manuelle bornée.
- Décision
- Ne pas valider le routage au seul rattachement d’une politique ; exiger une personne couverte et une notification témoin sur chaque fenêtre critique.
Le webhook resolved arrive avant un acknowledged retardé et rouvre la boucle ITSM
Le consommateur traite les notifications dans l’ordre d’arrivée. Après un délai ou une relivraison, acknowledged écrase resolved, remet le ticket en cours et peut déclencher une nouvelle mise à jour vers PagerDuty.
- Entrée
- Subscription ID, signature, event ID, event type, incident ID, occurred_at, ordre reçu, état relu, version interne, liaison ticket, autorité par champ et origine de la mutation.
- Sortie
- Vérification de signature, inbox idempotente, ordonnancement par incident, machine d’états monotone, relecture REST avant effet irréversible et marqueur anti-boucle.
- Décision
- Ne jamais faire du webhook isolé la vérité finale ; dédupliquer, comparer la version et relire l’incident avant de rouvrir ou clôturer un objet externe.
Chaîne de réponse aux incidents
Relier PagerDuty sans confondre signal, ticket et décision
Le monitoring détecte, PagerDuty orchestre l’astreinte et l’ITSM conserve le travail de support. Ces pages bornent les responsabilités voisines et les droits transverses.
Ciama suit les collectes instrumentées de leur mise en attente à leur résultat. Six statuts, une progression bornée, quatre compteurs, le contexte source et la durée rendent chaque run vérifiable. Une vue parent-enfants décompose les traitements multi-canaux sans masquer une branche en avertissement ou en échec.
Dawap a industrialisé la plateforme B2B de 1UP Distribution pour protéger commandes, droits, API et traitements Odoo à chaque évolution. Architecture par domaines, tests parallélisés, maintenance contrôlée, sessions préservées, observabilité et reprises bornées permettent aux clients et aux équipes commerciales, administratives et logistiques de continuer à travailler pendant que le produit évolue.
L’API PagerDuty orchestre alertes et escalades, mais Cette intégration peut réveiller plusieurs équipes pour le même incident. La décision doit s’appuyer sur le terrain pour dédupliquer, enrichir et résoudre les événements selon leur cycle réel, afin que l’astreinte reçoive le bon contexte et que la clôture technique reflète bien le retour à la normale.
Un mode opératoire d’incident API ne sert pas à documenter la panne, mais à trancher vite entre replay ciblé, correction source et isolement du flux. Quand ERP, CRM et e-commerce divergent, il réduit les faux diagnostics, protège les objets voisins et conserve la preuve qui permet au support de clôturer sans relancer une écriture déjà appliquée.
Questions d’achat
Questions fréquentes sur l’intégration PagerDuty API
Questions fréquentes sur PagerDuty API, cadrage, connecteur, sécurité, webhooks, quotas et run.
01Que peut automatiser un intégrateur PagerDuty API ?
Selon les droits disponibles : réception d’événements, enrichissement et déduplication d’alertes, lecture d’incidents, services, équipes, politiques ou schedules, notifications, liens ITSM et synchronisation contrôlée de statuts. Chaque parcours garde sa source de vérité et sa preuve.
02Quelle différence entre Events API v2 et REST API PagerDuty ?
Events API v2 sert à déclencher, acquitter ou résoudre un signal avec une routing key liée à une intégration de service. REST utilise une autre clé pour lire ou administrer les ressources autorisées. Nous séparons credentials, clients, droits et journaux.
03Comment éviter les incidents PagerDuty dupliqués ?
Le producteur définit une dedup_key déterministe, la conserve exactement — y compris sa casse — et la réutilise pour tout le cycle. Les réponses inconnues sont rapprochées avant tout nouveau trigger ou ticket.
04Comment vérifier qu’une escalade atteindra la bonne personne ?
Nous parcourons service, politique, niveaux, schedules, restrictions, overrides et fuseaux, puis testons une notification sur les fenêtres critiques. Une politique attachée ne suffit pas à prouver la couverture.
05Comment synchroniser PagerDuty avec un ITSM sans boucle ?
Le flux conserve la liaison incident–ticket, définit une autorité par champ, vérifie signature et event ID, tolère le désordre, relit l’état courant et marque l’origine de chaque mutation.
06Comment gérer webhooks et limites REST PagerDuty ?
Le consommateur V3 vérifie la signature du corps brut et déduplique les événements. Le client REST mesure les en-têtes de rate limit, ralentit avant épuisement et reprend depuis un checkpoint sans transformer une lecture partielle en zéro.
API DevOps, ITSM & observabilité
PagerDuty doit joindre la bonne personne sans fabriquer de bruit ni de faux statut ?
Dawap peut cadrer un signal témoin, prouver déduplication, couverture, transitions et boucle ITSM, puis ouvrir progressivement l’astreinte de production avec une reprise explicable.
Cadrer mon intégration PagerDuty