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