Photographies de livraison

Les photos prises à la réception, servies sous forme d'URL signées qui expirent au bout de quinze minutes.

Le personnel photographie ce qu'il réceptionne — une étiquette, une palette abîmée, une sonde posée contre un afficheur. Ces photos sont la preuve derrière isCompliant, et cet endpoint vous les transmet.

Il exige à la fois deliveries:read et delivery-images:read sur le restaurant présent dans le chemin. Une clé qui n'a que la première répond 403 ici, alors que la livraison elle-même répond normalement.

Lister les photographies d'une livraison

GET /v1/restaurants/{restaurantId}/deliveries/{deliveryId}/images

{
  "data": [
    {
      "id": "b4d81f0ac2e7",
      "contentType": "image/jpeg",
      "byteLength": 902450,
      "uploadedAt": "1787932860000",
      "url": "https://…/restaurants/restaurant-1/deliveries/8f2c…/b4d81f0ac2e7.jpg?X-Amz-Signature=…",
      "urlExpiresAt": "1787933760000"
    }
  ]
}

Il n'y a pas de pagination : une livraison contient au plus vingt photographies, et elles reviennent dans une seule réponse.

Champ	Type	Signification
`id`	string	Identifiant stable de la photo au sein de la livraison.
`contentType`	string	`image/jpeg`, `image/png` ou `image/webp`. Rien d'autre n'atteint cette API.
`byteLength`	integer	Taille exacte de l'objet, jusqu'à 10 Mo.
`uploadedAt`	string	Quand le téléversement de la photo s'est achevé, en millisecondes depuis l'epoch sous forme de chaîne de caractères.
`url`	string	Une URL signée, directe, vers les octets.
`urlExpiresAt`	string	Quand cette URL cesse de fonctionner, en millisecondes depuis l'epoch sous forme de chaîne de caractères.

Les URL sont volontairement à durée de vie courte

url est un lien pré-signé valable quinze minutes, et toutes les URL d'une même réponse partagent la même expiration, ce qui vous permet de traiter la page comme un tout. Il porte sa propre autorisation, donc récupérer les octets ne demande aucun en-tête Authorization — ce qui veut aussi dire que le lien est en lui-même un identifiant au porteur.

Cela détermine la façon dont vous devez l'utiliser :

Récupérez maintenant, ou récupérez à nouveau plus tard. Téléchargez les octets pendant que la réponse est fraîche ; ne stockez pas l'URL pour la suivre demain. Rappelez l'endpoint pour obtenir de nouveaux liens — c'est peu coûteux, et cela revérifie l'autorisation, ce qui est bien l'intérêt.
Ne mettez jamais l'URL là où elle survivra à son objet. Pas dans un e-mail, pas dans un ticket, pas dans un cache côté client avec un TTL long. Pendant quinze minutes, quiconque la détient peut lire cette photo.
Stockez les octets, pas le lien, si vous avez besoin de la photo dans votre propre produit. Gardez id à côté pour savoir si vous l'avez déjà.

Seules les photos téléversées apparaissent

Une photographie est enregistrée quand l'appareil commence le téléversement, et ne devient visible ici qu'une fois les octets réellement arrivés et vérifiés. Une photo encore en transit — un téléphone qui a quitté le bâtiment au milieu du téléversement — est absente plutôt que cassée.

C'est pourquoi imageCount sur la livraison peut brièvement dépasser ce que renvoie cet endpoint. Fiez-vous à cet endpoint pour ce qui existe maintenant, et relisez la livraison plus tard si un décompte compte pour vous.

Les récupérer

curl "https://api.backresto.com/v1/restaurants/$RESTAURANT_ID/deliveries/$DELIVERY_ID/images" \
  -H "Authorization: Bearer $BACKRESTO_PARTNER_API_KEY" \
  | jq -r '.data[] | "\(.id) \(.url)"' \
  | while read -r id url; do
      curl -sS "$url" -o "$id.jpg"
    done

L'en-tête Authorization sur le premier appel, et aucun sur le second : c'est la signature dans l'URL qui autorise le téléchargement.