Aller au contenu principal

Guide de référence JSON public Capgo API

Référence JSON publique complète Capgo API pour automatiser les mises à jour CapacitorJS. Couvre les schémas, l'authentification, les canaux et les modèles d'intégration CI/CD.

Guide de référence JSON public Capgo API

Un JSON API public L’interface permet aux logiciels d’échanger des données structurées via des requêtes et réponses HTTP. L’API typée et RESTful de Capgo offre aux équipes CapacitorJS et Electron un contrôle programmatique sur les live updates, les canaux, les bundles et la livraison sur les appareils.

Table des matières

Comprendre les fondamentaux du JSON de l'API publique Capgo

Capgo n’est pas un répertoire de données à usage général. Son interface JSON publique API relie votre système de build au service de livraison cloud de Capgo, ce qui permet à l’automatisation des releases de publier et de router des bundles web signés sans attendre la validation de l’App Store ou du Play Store. REST utilise des méthodes HTTP habituelles telles que GET, POST, PUT, PATCH et DELETE, le JSON servant généralement de format de réponse, comme expliqué dans ce guide REST API de Postman.

Une femme travaillant sur un ordinateur portable à un bureau avec une plante, une tasse de café et un carnet.

Pour Capgo, le JSON est le langage commun entre les scripts d'automatisation, les jobs CI/CD, les clients TypeScript et la plateforme de livraison. Cette cohérence rend les payloads lisibles dans les logs et simples à valider avant de lancer un déploiement.

Ce que contrôle l’interface

Utilisez les endpoints JSON publics de API pour gérer vos ressources opérationnelles de release, notamment :

  • Les bundles, les assets web et les métadonnées qui constituent une mise à jour déployable.
  • Canaux, comme staging, beta, production ou flux de release spécifiques à un client.
  • Versions, qui identifient et suivent les builds assignés à ces canaux.
  • Ciblage des appareils, ce qui permet de diriger les releases vers des plateformes, versions d’application, systèmes d’exploitation ou groupes de métadonnées spécifiques.
  • Données d’observabilité, y compris l’adoption, les échecs, l’activité de rollback et l’état par appareil.

Une requête typique suit une séquence prévisible. Votre pipeline crée ou prépare un bundle, envoie les métadonnées JSON à Capgo, vérifie le statut retourné, puis affecte la release à un canal approprié. Une requête ultérieure peut confirmer quels appareils ont reçu la mise à jour.

Idée clé : Considérez le JSON Capgo comme un contrat de contrôle de release, et non comme un simple format de données. Chaque champ doit permettre de publier, cibler, surveiller ou récupérer une mise à jour d’application.

Pourquoi le JSON typé est utile

Les payloads typés réduisent l’ambiguïté dans les bases de code TypeScript. Un identifiant de version doit rester une chaîne de caractères, un drapeau de déploiement progressif doit rester un booléen, et un nombre d’appareils doit rester numérique. Avant de connecter l’automatisation, définissez des interfaces pour les requêtes et les réponses, puis validez les champs obligatoires et les valeurs nulles.

Lire aussi : En savoir plus sur l’utilisation de TypeScript avec les API.

Adoptez trois habitudes dans chaque intégration :

  1. Inspecter les codes de statut et les corps de réponse ensemble, car le succès HTTP seul ne décrit pas nécessairement l’achèvement du déploiement.
  2. Conserver les identifiants retournés, notamment les identifiants de bundle, de version et de canal, pour les appels suivants.
  3. Log safely, en excluant les clés API et les données sensibles de l’appareil.

Les sections de référence suivantes s’appuient sur cette base pour expliquer l’authentification, les charges d’upload, les schémas de canal, les requêtes de ciblage et les objets d’erreur. Pour les noms d’endpoints et les définitions de champs actuels, consultez la documentation de Capgo à l’adresse capgo.app.

{ “authorization”: “Bearer VOTRE_CAPGO_API_CLÉ”,\n“contentType”: “application/json”,\n“accept”: “application/json”\n}

{ “success”: true, “bundleId”: “com.example.field-app”, “version”: “2.4.0”, “status”: “uploaded”, “bundleUuid”: “generated-bundle-identifier”, “createdAt”: “2026-01-15T10:30:00Z” }

{ “defaultVersion”: “2.4.3”, “autoUpdate”: true, “rollbackProtection”: { “enabled”: true, “fallbackVersion”: “2.4.2” } }

{ “data”: [ { “timestamp”: “2026-02-04T09:00:00Z”, “installs”: 842, “rollbacks”: 3, “errors”: 11 }, { “timestamp”: “2026-02-04T10:00:00Z”, “installs”: 1276, “rollbacks”: 2, “errors”: 8 } ], “summary”: { “totalInstalls”: 2118, “totalRollbacks”: 5, “totalErrors”: 19 } }

{ “error”: { “code”: “INVALID_PARAMETER”, “message”: “Le champ « version » est requis”, “field”: “version”, “details”: { “expected”: “string”, “received”: “null” } } }

{ “version”: “2.4.0”, “checksum”: “sha256-value”, “encryption”: true, “externalUrl”: “https://storage.example/bundle.zip” }

Live updates pour les apps Capacitor

Lorsqu'un bug de la couche web est en ligne, déployez le correctif via Capgo au lieu d'attendre des jours l'approbation des stores. Les utilisateurs reçoivent la mise à jour en arrière-plan, tandis que les changements natifs suivent le circuit de validation habituel.

Les derniers articles du blog

Capgo vous offre les meilleures informations pour créer une application mobile vraiment professionnelle.