Delivery photographs

The pictures taken at reception, served as signed URLs that expire in fifteen minutes.

Staff photograph what they receive — a label, a damaged pallet, a probe against a display. Those pictures are the evidence behind isCompliant, and this endpoint hands them to you.

It needs both deliveries:read and delivery-images:read on the restaurant in the path. A key with only the first answers 403 here while the delivery itself answers normally.

List the photographs of a delivery

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"
    }
  ]
}

There is no pagination: a delivery holds at most twenty photographs, and they come back in one response.

Field	Type	Meaning
`id`	string	Stable identifier of the picture within the delivery.
`contentType`	string	`image/jpeg`, `image/png` or `image/webp`. Nothing else reaches this API.
`byteLength`	integer	Exact size of the object, up to 10 MB.
`uploadedAt`	string	When the picture finished uploading, epoch milliseconds as a string.
`url`	string	A signed, direct URL to the bytes.
`urlExpiresAt`	string	When that URL stops working, epoch milliseconds as a string.

The URLs are short-lived on purpose

url is a pre-signed link valid for fifteen minutes, and every URL in one response shares the same expiry so you can treat the page as a unit. It carries its own authorisation, so fetching the bytes takes no Authorization header — which also means the link is a bearer credential in itself.

That shapes how you should use it:

Fetch now, or fetch again later. Download the bytes while the response is fresh; do not store the URL and follow it tomorrow. Call the endpoint again to get new links — it is cheap, and it re-checks the grant, which is the point.
Never put the URL somewhere it outlives its purpose. Not in an email, not in a ticket, not in a client-side cache with a long TTL. For fifteen minutes anybody holding it can read that picture.
Store the bytes, not the link, if you need the picture in your own product. Keep id alongside so you can tell whether you already have it.

Only uploaded pictures appear

A photograph is registered when the device begins the upload and becomes visible here only once the bytes have actually landed and been verified. A picture still in flight — a phone that left the building mid-upload — is absent rather than broken.

That is why imageCount on the delivery can briefly exceed what this endpoint returns. Trust this endpoint for what exists now, and re-read the delivery later if a count matters to you.

Fetching them

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

The Authorization header on the first call, and none on the second: the signature in the URL is what authorises the download.