Lieferfotos

Die bei der Warenannahme aufgenommenen Bilder, ausgeliefert als signierte URLs, die nach fünfzehn Minuten ablaufen.

Das Personal fotografiert, was es annimmt — ein Etikett, eine beschädigte Palette, einen Fühler an einer Anzeige. Diese Bilder sind der Beleg hinter isCompliant, und dieser Endpunkt gibt sie Ihnen heraus.

Er braucht beide Berechtigungen, deliveries:read und delivery-images:read, für das Restaurant im Pfad. Ein Schlüssel mit nur der ersten antwortet hier 403, während die Lieferung selbst normal antwortet.

Die Fotos einer Lieferung auflisten

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

Es gibt keine Paginierung: Eine Lieferung hält höchstens zwanzig Fotos, und sie kommen in einer einzigen Antwort zurück.

Feld	Typ	Bedeutung
`id`	string	Stabile Kennung des Bildes innerhalb der Lieferung.
`contentType`	string	`image/jpeg`, `image/png` oder `image/webp`. Nichts anderes erreicht diese API.
`byteLength`	integer	Genaue Größe des Objekts, bis zu 10 MB.
`uploadedAt`	string	Wann das Bild fertig hochgeladen war, als Zeichenkette mit Millisekunden seit der Epoche.
`url`	string	Eine signierte, direkte URL zu den Bytes.
`urlExpiresAt`	string	Wann diese URL aufhört zu funktionieren, als Zeichenkette mit Millisekunden seit der Epoche.

Die URLs sind absichtlich kurzlebig

url ist ein vorsignierter Link, der fünfzehn Minuten gültig ist, und jede URL einer Antwort hat denselben Ablaufzeitpunkt, Sie können die Seite also als Einheit behandeln. Er trägt seine eigene Autorisierung, das Abrufen der Bytes braucht also keinen Authorization-Header — was zugleich heißt, dass der Link selbst ein Bearer-Credential ist.

Das prägt, wie Sie ihn benutzen sollten:

Jetzt abrufen oder später neu abrufen. Laden Sie die Bytes herunter, solange die Antwort frisch ist; speichern Sie die URL nicht, um ihr morgen zu folgen. Rufen Sie den Endpunkt erneut auf, um neue Links zu bekommen — das ist billig, und dabei wird die Zuweisung erneut geprüft, worum es gerade geht.
Legen Sie die URL nie irgendwohin, wo sie ihren Zweck überlebt. Nicht in eine E-Mail, nicht in ein Ticket, nicht in einen clientseitigen Cache mit langer TTL. Fünfzehn Minuten lang kann jeder, der sie hat, dieses Bild lesen.
Speichern Sie die Bytes, nicht den Link, wenn Sie das Bild in Ihrem eigenen Produkt brauchen. Bewahren Sie id daneben auf, damit Sie erkennen, ob Sie es schon haben.

Nur hochgeladene Bilder erscheinen

Ein Foto wird registriert, wenn das Gerät den Upload beginnt, und wird hier erst sichtbar, sobald die Bytes tatsächlich angekommen und geprüft sind. Ein Bild, das noch unterwegs ist — ein Telefon, das mitten im Upload das Gebäude verlassen hat — fehlt, statt kaputt zu sein.

Deshalb kann imageCount an der Lieferung kurzzeitig höher sein als das, was dieser Endpunkt zurückgibt. Vertrauen Sie diesem Endpunkt für das, was jetzt existiert, und lesen Sie die Lieferung später erneut, wenn Ihnen eine Anzahl wichtig ist.

Sie abrufen

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

Der Authorization-Header beim ersten Aufruf und keiner beim zweiten: Die Signatur in der URL ist es, die den Download autorisiert.