BUG: Box_name field incorrect in orders and packs_per_day queries

GraphQL API
1

Hello! I’m just finding out today that many shipments that I’ve pulled via the API have incorrect values in the “box_name” field. This includes results for both the “orders” query and the “packs_per_day” query.

Using the orders query as an example, when I send this query:

query {
  orders(
    order_number: "S1412756"
  ) {
    request_id
    complexity
    data (first: 1) {
      pageInfo {
        hasNextPage
        endCursor
      }
      edges {
        cursor
        node {
        
          order_number
          box_name
          
        }
      }
    }
  }
}

I get back this result:

{
	"data": {
		"orders": {
			"request_id": "61e1e30eff5e40218b616315",
			"complexity": 2,
			"data": {
				"pageInfo": {
					"hasNextPage": false,
					"endCursor": "YXJyYXljb25uZWN0aW9uOjA="
				},
				"edges": [
					{
						"cursor": "YXJyYXljb25uZWN0aW9uOjA=",
						"node": {
							"order_number": "S1412756",
							"box_name": "Flat Rate Envelope"
						}
					}
				]
			}
		}
	}
}

But if I look at the same order in the ShipHero “Shipments Report” in the UI, it shows that the box_name is actually “9x7x4”. This is not an isolated incident. Thousands of our orders going back at least through the middle of December have incorrect “box_name” data coming from the API.

Looking at the spread of the API data versus the UI data, we suspect that the default box type selection that comes up when the package is being shipped is being reported via the API, but a separate field with the correct box selected during the shipping process is being reported via the UI. (especially because I can pull both versions “right now”)

Please let me know if you have any questions or need more examples. Like I said, I have thousands.

Thank you,
Jeremy

2

Hello @jeremyw!

No need for further explanation. You’ve been thorough!

I will run some tests and forward this to the engineering team if needed.

Have a great day!

TomasFD

1 Like
3

Oops! I left one point kind of half open by accident. I meant to say that this has been going on since at least December 13 or so. That’s how long I’ve been using the API to get that info, but I only found out today because of a report I compiled about our box usage over the last month so we could get more on order.

Thanks for your help, Tomas!

4

Hello @jeremyw!

I see what’s happening. Orders can have a box assigned, manually or by automation rule. This is the Flat Rate Envelope you see.

But, when packing out the order, you can change that box:

image
image1688×219 21.4 KB

So the order will show the box assigned to it, but the shipment will show the box that was entered at the moment of shipping. The query you are using polls the order’s box, and the shipments report the shipment’s box.

You can use these queries instead to poll the boxes that were used:

If you only know the order_number:

query {
  orders(
    order_number: "string"
  ) {
    request_id
    complexity
    data (first: 1) {
      pageInfo {
        hasNextPage
        endCursor
      }
      edges {
        cursor
        node{
          shipments{
            shipping_labels{
              box_id
            }
          }
        }
      }
    }
  }
}

If you know the order_id (the number you see in the URL when you are inside an order in the UI):

query{
  shipments(order_id:"string"){
    request_id
    complexity
    data(first:1){
      pageInfo{
        hasNextPage
        endCursor
      }
      edges{
        node{
          order_id
          shipping_labels{
            box_id
          }
        }
      }
    }
  }
}

Please let me know if this doesn’t help.

Have a great day!
TomasFD

5

Hey Tomas!

Thanks for the reply. Unfortunately that doesn’t really help me. It puts me right back at square one of the whole problem that I’ve had for a couple of years now. If I use either of your example queries to get the box from the shipment, I get a cryptic “4394”, which doesn’t help me. For my reporting, I need to know the descriptive version, such as “Flat Rate Envelope”, “9x7x4”, “Bubble Mailer” or whatever, so that I can let my team know what to order more of according to our demand. There’s no automated path to get from “4394” to “9x7x4” without manually maintaining an external lookup table. It feels like querying via the API should be able to supply that link for me in some way, even if there were just a separate “shipping box” query that just gives the lookup table.

The only reason I started using the box from the order was because it appeared to solve this issue. There was no caveat anywhere (that I saw) that said it wouldn’t be updated upon shipping the order, so I thought it was the solution to my problem. But it turns out it wasn’t. Bummer.

I think I’m just feeling frustrated because all of the data is obviously in ShipHero because it can be looked up in the UI and everything is correct, but I just don’t understand why I can’t get at the correct data with the API rather than having to do manual CSV exports via the UI and manually merge that data as a separate process. When it turns out that there’s a field like this in the API that doesn’t update when you change the drop-down in the UI, it just really feels like it should. Who wants to look up information that’s inaccurate? I can’t see how that sort of stale data is useful for anyone. If the field doesn’t give correct and up-to-date information, I think it’s broken and still consider it a bug.

/deep breaths/

I’m sorry for sounding ranty. I know it’s not your fault. I get that there’s a lot of behind-the-scenes stuff that has to happen to make something like this work, and I do appreciate that work. I think I just got my hopes up for the wrong thing.

Thanks,
Jeremy

6

Hello @jeremyw!

I do understand your frustration. I can create a feature request to add the box_name field to the shipments mutation. Would this help with this concern?

Kind regards,
TomasFD

7

Hi @tomasfd ,

The thread that I linked in my previous response was about trying to get that in the first place. Tomas W told me at the time “Unfortunately, we won’t be able to add this field.” If you can somehow get it to happen, and if it can be accurate based on what is scanned or selected by the user, then I’m definitely all for it.

Thanks,
Jeremy