Journal des modifications de l'API

L’API d’Uptrends est améliorée et complétée au fil du temps. Selon les besoins relatifs aux fonctionnalités, nous ajoutons de nouveaux endpoints et de nouvelles méthodes.

Lors de l’ajout d’une nouvelle fonctionnalité, notre objectif est de rester compatible avec les versions antérieures. Cependant, des changements sont parfois inévitables et une nouvelle version de l’API peut ne pas être compatible avec ce que vous avez codé et utilisé jusqu’à présent. Pensez donc à vérifier régulièrement le journal des modifications de l’API pour rester au courant des changements et agir en conséquence si nécessaire.

Si vous voulez consulter la documentation de l’API, reportez-vous aux articles de la catégorie API d’Uptrends.

De même, si vous souhaitez connaître les changements apportés à l’application Uptrends, consultez le journal des modifications général.

Juillet 2026

Gérer les configurations d’export OpenTelemetry avec la nouvelle MonitorResultExportSettings API

Un nouvel ensemble d’endpoints MonitorResultExportSettings a été ajouté pour vous aider à gérer votre configuration d’export OpenTelemetry d’Uptrends. L’API vous permet de créer, récupérer, mettre à jour et supprimer les connexions OpenTelemetry, les ensembles de règles et les paramètres d’export configurés dans Uptrends.

Pour en savoir plus, consultez la documentation Uptrends API v4 MonitorResultExportSettings.

Prise en charge de l’authentification Bearer dans les API Monitor et MonitorCheck

Les endpoints /Monitor et /MonitorCheck/{monitorCheckId}/MultiStepAPI prennent désormais en charge la configuration de l’authentification Bearer pour les moniteurs d’API multi-étapes. Une fois configuré, le bearer token est automatiquement inclus dans l’en-tête Authorization de la requête. Pour des raisons de sécurité, la valeur du token ne peut être récupérée depuis aucun endpoint.

Pour en savoir plus, consultez la documentation Uptrends API v4 Monitor et MonitorCheck.

Juin 2026

Mise à jour de l’API Monitor : savoir quel opérateur a apporté la dernière modification à un moniteur

L’endpoint /Monitor renvoie désormais la valeur LastModifiedByOperatorId, qui indique quel opérateur a créé ou modifié un moniteur en dernier.

Gérer les intégrations personnalisées avec les nouveaux endpoints Integration/Custom

Un nouvel ensemble d’endpoints Integration/Custom a été ajouté pour récupérer, créer, mettre à jour et supprimer des intégrations personnalisées. Pour en savoir plus, reportez-vous à la documentation de l’API v4 d’Uptrends sur l’endpoint Integration.

Gérer les utilisateurs d’API avec les nouveaux endpoints ApiUser

Un nouvel ensemble d’endpoints ApiUser a été ajouté pour récupérer, créer, mettre à jour et supprimer des utilisateurs d’API. Pour en savoir plus, reportez-vous à la documentation de l’API v4 d’Uptrends sur l’endpoint ApiUser.

Mars 2026

Gérer efficacement les sites web RUM avec l’API

Les sites web RUM sont désormais entièrement gérables par l’API. L’endpoint /RUM permet maintenant de créer, d’actualiser et de supprimer les configurations des sites web RUM, en plus de pouvoir les récupérer. Pour en savoir plus, reportez-vous à la documentation de l’API v4 d’Uptrends sur l’endpoint RUM.

Septembre 2025

Ajout du point de terminaison MonitorCheck pour les moniteurs API Postman

L’endpoint /MonitorCheck/{monitorCheckId}/PostmanAPI a été ajouté pour fournir des informations détaillées sur les vérifications individuelles effectuées par les moniteurs API Postman. Ces informations incluent des résultats importants, tels que le code de statut HTTP, les résultats des assertions, le temps total d’exécution, les éléments de la réponse et d’autres données sur chaque étape d’API.

Pour en savoir plus, reportez-vous à la documentation de l’API v4 d’Uptrends sur l’endpoint MonitorCheck.

Mise à jour de l’API Monitor : prise en charge des variables prédéfinies dans les moniteurs API Postman

L’endpoint /Monitor fournit désormais le champ PredefinedVariables pour les moniteurs API Postman. Ce champ contient toutes les variables définies par l’utilisateur et les variables de collection associées au moniteur.

"PredefinedVariables": [
    {
      "Key": "baseUrl",
      "Value": "{{prodEnvironment}}"
    },
    {
      "Key": "testEnvironment",
      "Value": "https://test-galactic.resorts.com/"
    },
    {
      "Key": "prodEnvironment",
      "Value": "https://https://prod-galactic.resorts.com/"
    },
    {
      "Key": "secretkey",
      "Value": "{{@VaultItem.70454a43-ef64-4f6a-aee0-3779654f1a31.Password}}"
    }
  ]

Pour en savoir plus, vous pouvez lire notre article sur les variables d’API Postman et la documentation de l’API v4 d’Uptrends sur l’endpoint Monitor.

Mise à jour de l’API Monitor : prise en charge des derniers agents utilisateurs d’Edge et de Chrome

L’endpoint /Monitor prend désormais en charge les valeurs d’agent utilisateur ChromeLatest et EdgeLatest correspondant aux dernières versions d’Edge et de Chrome. Vous pouvez aussi utiliser ces valeurs avec les méthodes /POST, /PUT et /PATCH.

Août 2025

Mise à jour de l’API Monitor : champs retirés

Depuis le 27 août 2025, certains champs de l’endpoint /Monitor ont été retirés. Pour définir des conditions d’erreur et préserver la compatibilité avec l’API d’Uptrends, veuillez utiliser la commande Monitor.ErrorConditions.

Mai 2025

Changement important à venir : retrait de champs d’API

Conformément à nos efforts continus pour optimiser l’API d’Uptrends, les champs suivants des endpoints Monitor seront retirés à compter du 27 août 2025 :

GET et POST /Monitor
GET, PUT et PATCH /Monitor/{monitorGuid}
GET et POST /Monitor/MonitorGroup/{monitorGroupGuid}

Les champs suivants seront désormais traités comme des types de conditions d’erreur dans le tableau ErrorConditions. Les champs connexes seront fusionnés sous la forme d’une seule entrée qui remplacera leur fonction individuelle :

Champs retirés	Nouveaux champs
`AlertOnLoadTimeLimit1`, `LoadTimeLimit1`	LoadTimeLimit1
`AlertOnLoadTimeLimit2`, `LoadTimeLimit2`	LoadTimeLimit2
`AlertOnMaximumBytes`, `MaximumBytes`	TotalMaxBytes
`AlertOnMinimumBytes`, `MinimumBytes`	TotalMinBytes
`AlertOnMaximumSize`, `ElementMaximumSize`	PageElementMaxSizeWithPercentage
`AlertOnPercentageFail`, `FailedObjectPercentage`	PageElementFailedWithPercentage
`ExpectedHttpStatusCode`, `ExpectedHttpStatusCodeSpecified`	HttpStatus

Voici un exemple de nouvelle réponse d’API. Nous vous recommandons de modifier vos appels d’API pour utiliser le tableau ErrorConditions. Vous utiliserez ainsi la structure d’API la plus récente, ce qui favorisera le bon fonctionnement de l’API.

{
  ...
  "ErrorConditions": [
    {
      "ErrorConditionType": "LoadTimeLimit1",
      "Value": "2500",
      "Effect": "Indicate"
    },
    {
      "ErrorConditionType": "LoadTimeLimit2",
      "Value": "5000",
      "Effect": "Error"
    },
    {
      "ErrorConditionType": "TotalMaxBytes",
      "Value": "5000000"
    },
    {
      "ErrorConditionType": "TotalMinBytes",
      "Value": "5000"
    },
    {
      "ErrorConditionType": "PageElementMaxSizeWithPercentage",
      "Value": "200000",
      "Percentage": "10"
    },
    {
      "ErrorConditionType": "PageElementFailedWithPercentage",
      "Percentage": "10"
    },
    { "ErrorConditionType": "HttpStatus",       
      "Value": "200"     
    }
  ],
 ...
}

Actualisation de l’endpoint Private Checkpoint Health

L’endpoint GET /PrivateCheckpointHealth renvoie désormais le champ Warnings, qui contient tous les avertissements liés au checkpoint du serveur. Pour en savoir plus, vous pouvez consulter la documentation sur l’endpoint Private Location Checkpoint de l’API v4 d’Uptrends.

Avril 2025

Ajout de nouveaux endpoints d’API pour les emplacements privés

Un nouvel ensemble d’endpoints d’API a été ajouté pour vous aider à gérer la configuration de vos emplacements privés, y compris les informations sur l’état de santé et les checkpoints. Pour en savoir plus, consultez la documentation de l'API v4 d’Uptrends sur les emplacements privés.

Mars 2025

Mise à jour de l’API Monitor Group

L’endpoint /MonitorGroup fournit désormais le nombre de crédits utilisés par type de moniteur:

UsedBasicMonitorQuota : fournit le nombre de crédits utilisés par les moniteurs de disponibilité et les moniteurs de base.
UsedBrowserMonitorQuota : fournit le nombre de crédits utilisés par les moniteurs de navigateur et les moniteurs Full Page Check.
UsedTransactionMonitorQuota : fournit le nombre de crédits utilisés par les moniteurs de transactions.
UsedApiMonitorQuota : fournit le nombre de crédits utilisés par les moniteurs d’API multi-étapes (MSA) et les moniteurs utilisant Postman.

Auparavant, l’API MonitorGroup API fournissait uniquement le nombre total de crédits disponibles pour chaque catégorie de moniteur. Elle renvoie désormais le nombre de crédits utilisés par chaque catégorie de moniteur.

Février 2025

Nouveauté concernant la valeur du paramètre Cursor

Le paramètre Cursor de l’API est une valeur de chaîne qui fonctionne comme un curseur pour parcourir les données de la réponse de l’API.

Les curseurs se présentent désormais sous la forme d’une chaîne plus longue afin de renforcer la sécurité des données. Les nouveaux curseurs créés suivent ce nouveau format, et les anciens curseurs continueront de fonctionner jusqu’au 1er avril 2025. Après cette période, ils ne pourront plus être utilisés. Nous vous recommandons de créer de nouvelles valeurs de curseurs pour que vos curseurs fonctionnent correctement.

Notez que le paramètre Cursor est disponible dans les endpoints des commandes Monitor Check et Alert de l’API.

Janvier 2025

Mise à jour de l’API Moniteur

L’endpoint /Monitor renvoie désormais la valeur LastModifiedDate, qui contient la date et l’heure de la dernière modification du moniteur. Auparavant, l’API Monitor renvoyait uniquement la valeur CreatedDate.

Journal des modifications de l’API