We have a 3PL account and we just set up the Shipment Update webhook (thanks for your help with that @tomasw ).
Now how do we determine which customer account the order that triggered the webhook is from? We need to set up the webhook for all our customer accounts but we need to know which customer it is from. I don’t see any way to determine that from the data received. The Generate Label webhook does provide the Company Name in the From Address but I don’t see anything like that from the Shipment Update webhook.
I really hope that it’s something simple that I missed.
It would be great if we could get the account_id as well as all the additional details in line_items. IIRC we get all that info from the Generate Label webhook which is why I was surprised that we’re not getting it on Shipment Update.
Yes, it’s the Shipment Update webhook, not the Generate Label one.
Can we get the account id, price and customs value added in? Or, even better, have all the same fields (where applicable) as the Generate Label webhook?
Just following up here - would it be possible to get those fields added in? That would save us the need to call the API multiple times to get that data. The savings would be significant on bulk shipments when we generate labels for 100s of orders at a time.
That said, I’m not even sure how I’d go about identifying which customer account this order is for so I can set the appropriate customer_account_id to query the additional data we need. If you can’t add in those fields to the webhook data, how can we achieve this?
Sorry for the late response. And thank you for submitting the Feature Request!
Forgive me as I’m not too familiar with GraphQL yet. Are you saying that I can use that query to pull just the single customer account record that is associated with the shipment that just came through? If so, how/where do I specify the ID of the account to pull?
And, more importantly, I don’t see a unique account ID in the data from the Shipment Update webhook that I can use to pull the account data. How can I get the ID of just the one account for whom the shipment was made?
Not one actually, you won’t be able to filter. But you should be able to pull them all at once, and those will never change, so you can store them and each time you get the webhook compare to which child account it belongs to
Correct, it is not available yet, I apologize for my confusion. But that is what the Feature Request is going to add to the webhook.
Let me know if I can provide a better explanation!
Thanks again!
Tom
One (hopefully) last thing - let’s say I store the accounts locally as you suggested. You mentioned that every time we get the webhook, we can compare it to see which child account it belongs to.
You mean when we get the Shipment Update webhook, we can compare the data in there to the locally stored accounts to determine which one it belongs to, right? But which piece of data do we compare if there are no account IDs in the Shipment Update webhook?
That is correct. So let’s assume the request gets approved and build, then the field will probably be something like "account_id":6334 and that you can compare it to your info taken from the Public API legacy_id:6334 and if they match, the order comes in from that Customer account
Ok that’s what I was afraid of. So, as a 3PL, there’s absolutely no way for us to associate shipments from the Shipment Update webhook with their corresponding accounts, right @tomasw ?
If so, this has just become a major roadblock in integrating our systems with Shiphero. Do you have an ETA to get a response as to whether the feature request will be implemented?
query{
shipment(id: "137328758"){
request_id
complexity
data {
order {
account_id
}
}
}
}
Being 137328758 the shipment ID from the webhook.
You could get the account_id from the customer that the order is for. This account ID should match the ID from the previous Query
With this option, every time we receive the Shipment Update webhook, we’d need to query the shipment to get the account_id. There are 2 issues here:
It’s an additional API call which slows down the process and, more importantly, adds a new point of failure (we might receive the webhook but an intermittent network issue might result in the query not running successfully).
During bulk shipments, we’d be hitting the API pretty hard which might result in us hitting out API rate limits.
In any case, this workaround is better than nothing so thank you for that! I’d really appreciate it if you could push on the feature request though.
Hi @afroznissar!
My apologies for the delayed update about this.
Unfortunately, the request has been rejected. We will keep this open in case there is a possibility of adding this in the future while doing some work on the webhooks.
Thanks again for the patience and we apologize for any inconvenience
Tom
