La surveillance API qui détecte la mauvaise réponse.

Votre point de terminaison de santé ne voit pas un parcours de connexion cassé. Uptimia se connecte, appelle l'API et vérifie les réponses — vous obtenez l'étape en échec, pas un ticket d'assistance.

Démarrer l’essai gratuit → Voir les tarifs
Essai gratuit de 30 jours · jusqu'à 50 sondes API Sans carte bancaire Conforme au RGPD
Intervalle le plus rapide
60s
Emplacements de confirmation
3
Points de contrôle
171+
Pays couverts
70+

La requête à la réponse erronée

Un parcours de commande en cinq étapes, exécuté selon une planification. La connexion, la recherche de commande et le total passent tous — la requête suivante, non.

étape 1 Connexion — récupération du jetonLa connexion réussit ; le jeton renvoyé atterrit dans {{token}} vous : tranquille
étapes 2–3 Appeler l'API avec ce jetonGET /orders récupère {{order_id}} ; la commande doit afficher le bon total vous : tranquille
étape 4 L'ajout de la note de commande échoueL'assertion nomme le problème : la note n'a jamais été créée vous : tranquille
14:32 Confirmé ailleurs — puis vous êtes alertéD'autres emplacements relancent le test et sont d'accord ; l'alerte nomme déjà l'étape 4 alerté : avec la cause
étape 4nommé dans l'alerte
« L'étape 4 a échoué à sa vérification. »14:32
C'est toute l'enquête, faite avant même que vous n'ouvriez votre ordinateur : l'étape, l'assertion, et la confirmation que ce n'est pas la mauvaise nuit d'une seule sonde. La correction commence à la requête en échec — pas à « l'API est en panne ».
étape en échec nomméeassertion exacte citéeconfirmé depuis d'autres emplacementsstatut · timing · en-têtes · valeurs — par étape
Et avec un simple ping ? /health continue de répondre parfaitement tout ce temps — une étape cassée en profondeur dans le parcours ne l'atteint jamais. Le premier signalement vient d'un client qui n'a pas pu terminer, suivi d'une recherche dans les journaux pour trouver où ça a coincé. découvert par un client

Ce qu'un ping ne voit jamais

Une requête qui réussit mais renvoie de mauvaises données reste un échec, et une étape cassée trois requêtes plus loin n'atteint jamais votre point de terminaison de santé. Pointez une sonde vers votre propre API — ou vers les API tierces dont vous dépendez, et sachez que le problème vient d'elles, pas de vous.

Codes de statut & en-têtesLa réponse attendue, à chaque étape
Valeurs dans la réponseN'importe quel champ, vérifié étape par étape
Échecs en plein milieu du parcoursL'étape 3 échoue — un ping ne le voit jamais
Dérive de la réponseStructure incorrecte, champs manquants
15 étapes par chaîne le parcours complet, exécuté pour de vrai
Échecs d'authentificationJetons expirés, connexions rejetées
Erreurs TLS & de connexionPoignées de main et sockets refusées
Budget de temps de réponseChaque étape sous sa limite
Les alertes nomment l'étape et l'assertion qui ont échoué : une requête en échec, une valeur incorrecte dans la réponse, un champ manquant, une étape lente, une erreur de connexion ou une connexion qui a cessé de fonctionner. étape + assertion

Chaînes, assertions et timing

Le parcours

Enchaînez jusqu'à 15 requêtes

Chaque étape peut extraire une valeur de la réponse — un jeton, un identifiant de commande — dans une variable que les étapes suivantes réutilisent sous la forme {{name}}. Une seule sonde couvre tout le parcours, de la connexion au nettoyage.

  • 6 méthodes HTTP — GET, POST, PUT, PATCH, DELETE ou HEAD, dans n'importe quel ordre
  • Extraction en variables — référençables ensuite n'importe où en aval sous la forme {{name}}
  • En-têtes, corps et délai d'expiration personnalisés par étape — dupliquez une étape pour construire rapidement
Rejouez le même parcours dans un vrai navigateur →
POST/auth/login1 assertion
{{token}}extrait → étapes suivantes
GET/orders2 assertions
{{order_id}}
GET/orders/{{order_id}}3 assertions
POST/orders/{{order_id}}/notes1 assertion
DEL/sessions/{{token}}nettoyage
Chaîne réussie1.94 s
Une seule sonde exécute tout le parcours — de la connexion au nettoyage — jusqu'à une fois par minute.
5 étapes7 assertions2 variables
Une étape sans assertion reste réussie tant que la requête aboutit — n'ajoutez des vérifications que là où elles comptent. tout succès
Assertions

Vérifiez le statut, les valeurs et le timing

Ajoutez les contrôles qu'une étape doit réussir : un statut exact, un budget de temps de réponse, une valeur dans le corps de la réponse, un en-tête, ou du texte dans la réponse. En cas d'échec, l'exécution montre ce qui a été obtenu — et Lancer le test interroge le point de terminaison réel avant l'enregistrement.

  • Statut et temps de réponse — l'étape échoue si le code est incorrect ou la réponse trop lente
  • Valeurs dans la réponse — ciblez un champ et exigez qu'il soit présent, et correct
  • En-têtes de réponse et texte du corps — exigez une valeur d'en-tête, ou du texte devant être présent ou absent
Surveillez du texte sur une page, pas seulement un statut →
Lancer le test200 · 191 ms
GET /orders/8842 · étape 3 — la réponse en direct, interrogée réellement avant l'enregistrement.
{
  "id": 8842,
  "status": "paid",
  "total": 4210
}
le statut est 200obtenu 200
$.status égale « paid »obtenu « paid »
temps de réponse inférieur à 500 msobtenu 191 ms
{{order_id}} extrait = 8842 alimente l'étape suivante — mis en évidence dans la réponse en direct ci-dessus. = 8842
Timing

DNS, TLS ou votre propre backend

« L'API est lente » n'est jamais toute l'histoire. Le temps de chaque étape est découpé en cinq phases — DNS, connexion, TLS, attente, réception — pour que vous voyiez quelle étape traîne et si le réseau ou votre backend en est la cause.

  • Timing en cinq phases par étape — DNS, connexion, TLS, attente, réception
  • Graphique du temps de réponse par étape — empilé, avec repères d'incidents
  • Étape la plus lente et exécutions les plus lentes affichées sur la page de détail de la sonde
Timing phase par phase pour les pages web →
Étape 4 — lente14:32:16
POST /orders/8842/notes · 1 389 ms au total, réparties en cinq phases.
dns18 ms
connexion31 ms
tls44 ms
attente1,284 ms
réception12 ms
Réseau — au vert
dns 18 · connect 31 · tls 44
93 ms
Backend — le frein
temps de réflexion avant le premier octet
1,284 ms
L'étape la plus lente et les exécutions les plus lentes figurent sur la page de la sonde — un graphique empilé par étape montre quand le ralentissement a commencé. la plus lente
Secrets

Vraies clés API, toujours masquées

Stockez mots de passe, clés API et jetons comme variables secrètes : en écriture seule, masquées à la lecture, et occultées dans les URL, en-têtes et extraits de réponse renvoyés. Rien de sensible ne finit dans votre historique d'exécution.

  • Variables secrètes en écriture seule — masquées à chaque relecture
  • Occultées partout où elles sont répercutées — URL, en-têtes et extraits de corps
  • Les valeurs extraites correspondant à un secret ne sont elles non plus jamais répercutées
Surveillez des pages protégées par une connexion →
API_KEYsecret
••••••••••••••••écriture seule
Stocké une fois, jamais réaffiché — une lecture renvoie value:'' · has_value:true.
En-tête de l'étape 1 — ce que vous configurez
Authorization: Bearer {{API_KEY}}
clé réelle injectée à l'envoi — en mémoire uniquement, jamais stockée
Historique d'exécution — ce qui est stocké
Authorization: Bearer [redacted]
Les valeurs extraites correspondant à un secret ne sont elles non plus jamais répercutées — rien de sensible n'atterrit dans l'historique d'exécution. masqué

Enchaînez les requêtes une seule fois.Obtenez le nom de l'étape en échec.

Chaque étape, chaque assertion, chaque canal d'alerte — gratuit pendant 30 jours, et rien de tout cela n'est un module payant.

Démarrez votre essai gratuit de 30 jours →
30 jours gratuits sans carte bancaire résiliable à tout moment

Comment fonctionne la surveillance API

Construisez la chaîne, validez-la contre l'API en direct, puis Uptimia l'exécute selon un horaire depuis notre réseau — rien à installer.

Étape 1construire

Enchaînez vos requêtes

Ajoutez chaque requête dans l'ordre, définissez en-têtes et corps, et extrayez dans des variables les valeurs dont les étapes suivantes ont besoin.

Étape 1 · requête
POST /auth/login
extraire $.token → {{token}}
Étape 2 · requête
GET /orders
Étape 2valider

Ajoutez des assertions et lancez un test

Ajoutez les contrôles que chaque étape doit réussir, puis lancez le test contre le point de terminaison réel — résultats complets par étape, avant l'enregistrement.

Assertions · étape 3
le statut est 200$.status = "paid"
sous 500 ms
Test lancé · 5/5 étapes réussies en 1,9 s
Étape 3chaque minute

Nous l'exécutons selon un horaire

Une sonde exécute toute la chaîne en un seul aller-retour, vérifie chaque assertion et stocke les résultats par étape — les échecs sont confirmés depuis d'autres points de contrôle avant l'alerte.

Exécution OK — 5/5 étapes
14:31 · 1,8 s · toutes les assertions réussies
à l'heure
Exécution échouée — étape 4
14:32 · 201 attendu, 500 obtenu
alerte en cours

Également inclus

Slack, PagerDuty, SMS et 9 autres

Une alerte API nomme l'étape en échec et sa cause, envoyée aux mêmes contacts que toutes les sondes Uptimia — e-mail, SMS, Slack, Teams, Discord, PagerDuty, webhooks et plus.

étape 3 · $.status : « paid » attendu, « pending » obtenu → Slack · E-mail · PagerDuty

Confirmé depuis d'autres points de contrôle avant l'alerte

Une exécution en échec est d'abord relancée depuis d'autres emplacements disponibles.

relancé ailleurs · confirmé avant ouverture

Dupliquer une étape

Construisez une longue chaîne rapidement — copiez une requête et ajustez-la.

étape 3 → dupliquer → étape 4

Export RCA de l'incident

Un incident clos conserve le détail au niveau des étapes — exportez-le.

RCAPDFHTML

Délai d'expiration, en-têtes et corps par requête

Donnez à chaque requête son propre délai d'expiration, ses propres en-têtes et son propre corps.

délai d'expiration 10 s · 20 en-têtes · corps 64 Ko

Tous les types de sondes dans un seul compte

Vos sondes API se retrouvent aux côtés de vos sondes de disponibilité, SSL, signal de présence et DNS — mêmes contacts, groupes et rôles.

Checkout order flowAPI www.caldmont.comUPTIME db-backup · nightlyHEARTBEAT

Qu'est-ce que la surveillance API ?

La surveillance API est un service automatisé qui exécute, selon un horaire, une véritable séquence de requêtes HTTP contre votre API REST ou votre point de terminaison JSON, et vous alerte quand une étape renvoie le mauvais statut, de mauvaises données, ou prend trop de temps. Elle surveille le parcours derrière un point de terminaison, pas seulement si le serveur a répondu.

Pendant que tout fonctionne

Comment fonctionne la surveillance API ?

Uptimia
exécute la chaîne
5 étapes · planifiées
Votre API
chaque vérification réussit

Une sonde exécute chaque étape en un seul aller-retour, évalue chaque assertion, et stocke les résultats par étape dans l'historique d'exécution.

Quand une vérification échoue

Confirmer d'abord, alerter ensuite

Votre API
étape 4 · échec
relance · autres emplacements
Uptimia
ouvre l'incident

l'étape 4 a échoué à sa vérification → l'incident s'ouvre, l'alerte nomme l'étape

Les vérifications

Que vérifie une sonde API ?

Une étape réussit par défaut dès que la réponse aboutit. Ajoutez des assertions et l'exécution doit les prouver — un statut exact, un budget de temps de réponse, une valeur dans la réponse, un en-tête, ou du texte dans le corps.

Outil gratuit : vérifier le statut et les en-têtes de n'importe quel point de terminaison →
VérificationCe qu'elle prouveExemple
Code de statutle point de terminaison a répondu comme attenduest 201 · est l'un des 200/204 · n'importe quel 2xx
Temps de réponsel'étape est assez rapidesous 500 ms
Corps JSONla réponse contient les bonnes données$.status égale « paid »
En-têtele bon type de contenu ou la bonne règle de cacheContent-Type contient json
Texte du corpsun marqueur est présent ou absentcontient « order created »

FAQ sur la surveillance API

01Qu'est-ce que la surveillance API ?+
Un service automatisé qui exécute, selon un horaire, une véritable séquence de requêtes HTTP contre votre API et vérifie les réponses. Une sonde Uptimia enchaîne jusqu'à 15 requêtes et vous alerte quand une étape renvoie le mauvais statut, de mauvaises données, ou prend trop de temps. On parle aussi de surveillance API synthétique ou de contrôle de santé API automatisé.
02En quoi est-ce différent d'un simple ping de disponibilité ?+
Un ping vous dit que le serveur a répondu. La surveillance API exécute tout le parcours et vérifie la réponse elle-même — code de statut, temps de réponse, en-têtes et valeurs dans le JSON. Un 200 qui renvoie de mauvaises données est détecté ici et reste invisible à un simple ping.
03À quelle fréquence Uptimia exécute-t-il ma vérification API ?+
Par défaut toutes les 5 minutes, et jusqu'à une fois par minute — le balayage de planification s'exécute chaque minute, donc une minute est le minimum.
04Combien d'étapes une sonde peut-elle avoir ?+
Jusqu'à 15 requêtes HTTP dans une même chaîne, chacune avec jusqu'à 20 en-têtes, 15 assertions et 10 extractions de valeurs. Le délai d'expiration par étape va de 1 à 60 secondes, et toute la chaîne dispose d'un budget d'exécution de 90 secondes.
05Exécute-t-elle du JavaScript ou rend-elle la page comme un navigateur ?+
Non. La surveillance API envoie de simples requêtes HTTP — pas de navigateur headless, pas de JavaScript, pas de captures d'écran. Pour faire parcourir un flux rendu par un vrai navigateur, utilisez la surveillance des transactions d'Uptimia ; la surveillance API est l'outil plus léger et plus rapide pour l'API elle-même.
06Puis-je vérifier une valeur à l'intérieur de la réponse JSON ?+
Oui. Pointez un sélecteur JSONPath vers le champ et vérifiez qu'il existe, égale une valeur, contient quelque chose, ou fait partie d'un ensemble. Vous pouvez aussi extraire une valeur dans une variable et la réutiliser dans les étapes suivantes sous la forme {{name}}. Le support JSONPath est un sous-ensemble ciblé, adapté aux réponses API classiques.
07Prenez-vous en charge GraphQL ou les WebSockets ?+
GraphQL fonctionne comme un simple POST HTTP — envoyez la requête dans le corps et vérifiez le JSON renvoyé — mais il n'existe pas de constructeur dédié à GraphQL. Les WebSockets ne sont pas pris en charge ; la surveillance API couvre les échanges requête/réponse en HTTP (GET, POST, PUT, PATCH, DELETE, HEAD).
08Puis-je importer une commande cURL ou partir d'un modèle ?+
Pas dans cette version. Vous construisez chaque étape dans l'éditeur — méthode, URL, en-têtes, corps, assertions, extractions — et pouvez dupliquer une étape pour avancer vite. L'import cURL et une bibliothèque de modèles ne font pas encore partie de la surveillance API.
09Comment évitez-vous les fausses alertes ?+
Une exécution en échec est relancée depuis d'autres points de contrôle avant l'ouverture d'un incident — par défaut, trois points de contrôle doivent être d'accord (l'original plus deux relances) avant que vous ne soyez alerté. Le rétablissement, lui, est rapide : une seule exécution réussie clôt l'incident et envoie l'avis de rétablissement.
10Mes clés API sont-elles en sécurité dans une vérification ?+
Stockez les identifiants comme variables secrètes : en écriture seule, masquées à la lecture, et occultées dans les URL, en-têtes et extraits de réponse renvoyés — rien de sensible n'atterrit dans votre historique d'exécution.
11La surveillance API est-elle un module payant ?+
Non. Chaque forfait inclut la surveillance API aux côtés de la disponibilité, du SSL, des transactions, du DNS et du signal de présence — jamais en module payant. Même le forfait gratuit inclut une sonde API ; les forfaits ne diffèrent que par le nombre inclus, et l'essai gratuit de 30 jours en inclut jusqu'à 50, sans carte bancaire.

Commencez à surveiller votre API dès aujourd'hui.

Construisez la chaîne, testez-la sur le point de terminaison en direct — et la prochaine fois qu'une étape casse, l'alerte vous dira déjà laquelle.

Démarrer l’essai gratuit →
Essai gratuit de 30 jours Jusqu'à 50 sondes API Sans carte bancaire Conforme au RGPD
La surveillance API rejoint la disponibilité, le SSL, la vitesse, les transactions, le DNS et le signal de présence sous une seule connexion Uptimia.