POs not showing attachments in API response

GraphQL API
1

Hi there,

we’re pulling purchase order data via your Public GraphQL API and warehouse-uploaded photos are visible in the ShipHero web UI but completely absent from the API response.

  • In the web UI our PO shows 3 attachments, including an images uploaded by warehouse users.
  • Via the API, the same PO returns:
    • attachments → only 1 node, a PDF that my user attached directly to the PO
    • pdf → the system-generated PO document
    • images → null

So the warehouse user’s image appears in neither attachments nor images. My token has full view:purchase_orders scope and reads the PO fine otherwise.

Questions:

  1. Are warehouse-user-uploaded PO photos exposed through the Public API at all? If so, in which field/type?
  2. Is this an account/warehouse scoping issue — i.e., are photos uploaded by a warehouse user tied to a separate scope my token can’t see?
  3. If there’s a setting or a warehouse-scoped token needed to retrieve these, please advise.

Thanks!

2

Hi @snowfreaks !

You are using something like this, right?

query {
  purchase_order(id: "569020") {
    request_id
    complexity
    data {
      attachments {
        edges {
          node {
            url
            filename
          }
        }
      }
    }
  }
}

(just tried that in my account and returns 2 images and a PDF for me)

3

Thanks @tomasw ! Yes, that’s the exact query I’m running, against my own PO.

The difference: in your account it returns 2 images + a PDF, but in mine the same query returns only 1 node — the PDF I attached directly to the PO. The 3 warehouse-user-uploaded photos that show in the web UI are still completely absent, and images is null. My token has full view:purchase_orders scope and reads everything else on the PO fine.

Since it works for you but not for me with identical queries, this looks like an account/warehouse scoping difference rather than a query issue. Could you address the original questions directly?

  1. Are warehouse-user-uploaded PO photos exposed through the Public API at all, and in which field/type?
  2. Is this a warehouse-scoping issue — are photos uploaded by a warehouse user tied to a scope my token can’t see?
  3. If a specific setting or warehouse-scoped token is required to retrieve them, what’s needed?

Happy to share a request ID privately if that helps you trace it on your end.

4

This appears to be the same thing that was reported back in 2022:

5

Apologies for that!

  1. Are warehouse-user-uploaded PO photos exposed through the Public API at all, and in which field/type? Yes, should be on the query exposed above
  2. Is this a warehouse-scoping issue — are photos uploaded by a warehouse user tied to a scope my token can’t see? Could be related to warehouse permissions, but could not reproduce this by assigning my user to a different warehouse.
  3. If a specific setting or warehouse-scoped token is required to retrieve them, what’s needed? Same as before, could not reproduce

The request ID would be great to dig deeper!

So far, tried assigning myself to a specific warehouse, making my user non-admin, or making the uploads from the child or 3pl and query from the other account, but no luck reproducing the behavior :man_shrugging:

6

I’ve run into this exact issue before. The attachment data usually isn’t included in the standard PO response by default—you’ll need to explicitly request it through the API.

A few things to check:

1. Query parameters: Most PO APIs require you to pass an include=attachments parameter or similar. Without it, the response strips out nested objects to keep payloads lean. Check your API documentation for the exact parameter name, as it varies (sometimes it’s expand, fields, or relations).

2. Endpoint differences: If you’re hitting the base /purchase-orders/{id} endpoint, try the /purchase-orders/{id}/attachments endpoint instead. Some systems separate attachment retrieval entirely, which is actually more efficient if you only need them sometimes.

3. Permissions and API version: Verify your API token has attachment read permissions. Also confirm you’re not accidentally on an older API version that doesn’t support attachment returns at all—I’ve seen this happen when teams upgrade their API client but the integration still points to v1.

4. Response format: Even when included, attachments might come back as just metadata (filename, size, ID) rather than the actual binary data. You’d then need a second call to /attachments/{id}/download to retrieve the file itself.

What endpoint are you calling, and does your API docs mention attachment inclusion at all? That’ll help narrow it down faster.