Vérifier l’état d’un envoi groupé de photos

Permet de consulter périodiquement l’état d’un envoi groupé asynchrone de photos. Lorsqu’un lot est suffisamment volumineux, ajouter des photos à un établissement le traite en arrière-plan et renvoie un requestId dans l’objet request au lieu des médias traités. La taille du lot qui déclenche ce comportement dépend d’une configuration côté serveur plutôt que d’une constante publiée ; déterminez donc le mode de traitement en vérifiant si request.requestId a été renvoyé, et non en comptant vos propres images. Interrogez périodiquement cet endpoint avec ce requestId jusqu’à ce que la tâche atteigne un état final.

Cas d’utilisation : alimenter une barre de progression de l’envoi. Après l’envoi d’un lot volumineux, interrogez cet endpoint toutes les quelques secondes tant que status vaut PROCESSING. Dès qu’il passe à SUCCESS ou à ERROR, consultez le tableau photos pour connaître le résultat de chaque image : chaque entrée contient le mediaId obtenu (en cas de réussite) ainsi qu’une paire status/errorMessage, afin que vous puissiez indiquer précisément quels fichiers ont été rejetés et pourquoi (dimensions incorrectes, format non pris en charge, etc.) plutôt que de faire échouer l’ensemble du lot.

Valeurs d’état : PROCESSING (traitement toujours en cours : interrogez à nouveau cet endpoint), SUCCESS (la tâche a terminé le traitement), ERROR (la tâche elle-même a échoué ; examinez photos[].errorMessage).

Pour la tâche, status indique uniquement que le traitement est terminé, et non que toutes les images ont été traitées avec succès. Une tâche à l’état SUCCESS peut tout de même contenir des photos rejetées, comme dans l’exemple ci-dessus. Dès que la tâche quitte l’état PROCESSING, parcourez photos[] et consultez les valeurs status et errorMessage propres à chaque entrée pour savoir quelles images ont été ajoutées.

Point d’attention concernant les interrogations périodiques : espacez les requêtes : une boucle sans pause sur cet endpoint risque de déclencher rapidement 429. Respectez l’en-tête Retry-After et privilégiez un intervalle de quelques secondes. Un requestId inconnu ou expiré ne permettra pas d’obtenir de résultat ; n’interrogez donc cet endpoint qu’avec des identifiants renvoyés par un appel d’envoi récent.