API v3.1

Toutes les routes de la v3.1 se trouvent sous le chemin de base /api/v3.1, sur l’hôte de l’API client qui vous est communiqué lors de l’onboarding. Le chemin de base de la v3.1 ne partage aucune route avec /api/v3 : un appel à /api/v3.1/containers n’atteint jamais un handler de la v3, et un appel v3 n’atteint jamais un handler de la v3.1.

https://<client-api-host>/api/v3.1/containers
Authorization: Bearer liv_<prefix>_<secret>

• La v3.1 ne sert que les plateformes V3. Une clé dont la plateforme n’est pas sur l’application utilisateur V3 reçoit 403 PLATFORM_NOT_V3.
• Un conteneur créé via la v3.1 est marqué comme créé par l’API. Un conteneur créé par la v3 ou par l’ancienne stack n’est pas visible depuis la v3.1, et un conteneur v3.1 n’est pas visible depuis la v3.
• Votre clé doit porter exactement une contrainte de plateforme. Une clé sans contrainte, ou avec plusieurs, reçoit 403 INVALID_PLATFORM_CONSTRAINTS.

La plupart des appels ressemblent à leurs équivalents v3. Voici les changements qu’un intégrateur doit anticiper.

Le tableau liste chaque route de la v3.1, le scope dont sa clé a besoin et la page qui la documente. Une route absente de ce tableau n’existe pas en v3.1.

Les erreurs utilisent l’enveloppe de la v3 : un objet avec un code en majuscules et un message en anglais. Lisez le code, pas le texte du message.

{
  "error": {
    "code": "MODE_MISMATCH",
    "message": "Container is a single-message container; a contributor token cannot be issued."
  }
}