# Get a proof of delivery

`GET /v2/shipments/pod?tracking_reference=UASDRW78`

**Base URLs:**

- Sandbox: `https://api.sandbox.bobgo.co.za`
- Production: `https://api.bobgo.co.za`

**Authentication:** Bearer token required (see the Authentication page).

## Example request

```bash
curl -X GET 'https://api.sandbox.bobgo.co.za/v2/shipments/pod?tracking_reference=UASDRW78' \
  -H "Authorization: Bearer <API_KEY>"
```

Returns the courier's proof of delivery for a shipment, typically a signature
or a delivery photograph.

| Name | Type | Required | Notes |
| --- | --- | --- | --- |
| `tracking_reference` | string | yes | Bob Go's tracking reference for the shipment. |

## Response

```json
{
  "pods": [
    {
      "data": "",
      "extension": ".pdf",
      "url": "https://..."
    }
  ],
  "count": 1
}
```

| Field | Notes |
| --- | --- |
| `data` | The document itself, base64-encoded, from the few couriers that send the file. Empty otherwise. |
| `extension` | What it is, with a leading dot: `.pdf`, `.png` or `.jpg`. Depends on the courier. |
| `url` | A link to the document. Most couriers provide this rather than `data`. |

A shipment can have more than one POD, so `pods` is an array; `count` is how
many there are.

A POD only exists once the courier has delivered the parcel **and** uploaded
it, which can lag delivery by a day or more, and not every courier supplies
one. An empty `pods` array is normal rather than an error. Retry later, and
don't block your flow on it.

A tracking reference that does not exist, or is not on your account, comes back
as a `404` with the same message either way, so the response never confirms
that another account's reference exists. A failure on our side, such as a
database error, is a `500`. When the courier's own lookup fails, its status is
passed on, so some couriers answer a shipment with no POD yet with a `400`
instead of an empty `pods` array. Read the message before retrying.
