- Démarrage
- Définition Swagger
- API Orchestrator
- Requêtes relatives aux actifs
- Requêtes de calendriers
- Requêtes relatives aux environnements
- Requêtes de dossiers
- Requêtes de tâches génériques
- Requêtes relatives aux tâches
- Requêtes relatives aux bibliothèques
- Requêtes relatives aux licences
- Requêtes relatives aux paquets (Packages Requests)
- Requêtes relatives aux autorisations
- Requêtes relatives aux processus
- Requêtes relatives aux Robots
- Requêtes relatives aux rôles (Roles Requests)
- Requêtes relatives aux planifications
- Requêtes relatives aux paramètres
- Requêtes de tâches
- Demandes de catalogues de tâches
- Demandes de formulaires de tâches
- Requêtes relatives aux locataires
- Requêtes relatives aux transactions
- Requêtes relatives aux utilisateurs
- Requêtes relatives aux Webhooks
Lisez-moi
Nous prévoyons de mettre à niveau la version Orchestrator Swagger vers Swagger 3.0. Les API Orchestrator sont actuellement définies à l’aide de Swagger 2.0.
Ne vous inquiétez pas de la rétrocompatibilité avec vos clients API existants : nous veillerons à ce que l'API reste compatible.
Nous vous recommandons d’utiliser vos clients précédents, car les modifications JSON ne les modifient pas, grâce à la rétrocompatibilité de notre structure de requête.
Après la mise à jour vers Swagger 3.0, il sera nécessaire de réajuster en fonction de la nouvelle définition JSON l’ensemble des clients API à nouveau générés.
Si vous prévoyez d'intégrer nos API à votre client, vous devez être conscient des mises à jour et des modifications possibles qui peuvent survenir à la définition Swagger, aux schémas JSON ou aux points de terminaison d'API.
La liste ci-dessous fournit des informations et des recommandations concernant les modifications apportées à Swagger. Si vous avez d'autres questions, contactez notre équipe d'assistance.
- La description de l'API JSON représentée dans le document Swagger JSON peut changer à tout moment. Cependant, il décrira la même API sous-jacente, pour assurer la rétrocompatibilité.
- L'interface Swagger et le JSON correspondant sont générés en fonction des points de terminaison actuels, et nous publions toujours la dernière version. Pour garantir la rétrocompatibilité, nous prenons en charge la même structure de requête.
- Comme alternative aux clients API générés au runtime, utilisez des clients API à temps fixe ou à temps de compilation. Cela réduit la dépendance et empêche les mises à jour d'automatisation majeures en cas de modification de l'API ou de la définition Swagger.
- Les éléments marqués comme obsolètes sont disponibles pendant une durée limitée, après quoi les éléments sont supprimés de la définition Swagger et de l'API JSON.
- Chaque fois que certaines API changent en interne, une nouvelle version de l'API Swagger est publiée. Le numéro de version de l'API n'influence pas l'utilisation de l'API cliente. Nous vous déconseillons de vous fier à la gestion des versions de l’API.