Clarification on inventory-update webhook data

Legacy REST API
1

The inventory-update webhook sends a payload that looks like:

{'inventory': [{'sku': 'BA7590-90',
   'virtual': False,
   'inventory': '2',
   'backorder_quantity': '0'}],
 'account_id': '1234'}

whereas GraphQL product query will return something of the form:

{'on_hand': 0,
   'allocated': 0,
   'available': 0,
   'backorder': 0,
   'warehouse_id': 'ABCDEFG',
   'inventory_bin': '1.C.3.G'}
  1. Can we get clarification on the inventory field on the webhook? Is it on_hand or available?
  2. Does the webhook fire on changes for on_hand only? Or will it fire for changes to availability (such as an order re-ship)?
  3. Would it be possible to get parity between the two and include all of the inventory fields on the webhook?

Thanks,
Diavd

2

Hi @David!

  1. Can we get clarification on the inventory field on the webhook? Is it on_hand or available?

The inventory field refers to the On Hand.

  1. Does the webhook fire on changes for on_hand only? Or will it fire for changes to availability (such as an order re-ship)?

If a order get re-shiped it should trigger the webhook when stock gets added back, yes.

  1. Would it be possible to get parity between the two and include all of the inventory fields on the webhook?

I’ll make the request for this, for inventory on webhook to change to on_hand, but need to check with the team because this may affect customers that already have it working like this.

Let me know if there’s anything else I can help you with,
Thanks!
Tom

3

Hi @tomasw ,

Thanks for the response. To add a bit more clarity, our concern is around some of the edge cases and making sure that we have current information about available and allocated as well as on_hand and backordered.

Here a situation:

  1. Product has 2 on hand, 2 available, 0 allocated and 0 on back order.
  2. We have to re-ship due to a lost package. In this case, we will not do an add back in the re-ship dialog.
  3. This will update ShipHero to 2 on hand, 1 available, 1 allocated and 0 on back order.

For us, we would want the webhook to fire even though the on_hand count hasn’t changed. Right now though, even if it does fire, it doesn’t provide any interesting information because available and allocated are not returned (but they are definitely interesting!)

I think that the change being requested is just to add these two additional fields. We can certainly live with the name discrepancy now that we’ve confirmed it is on_hand.

Thanks,
David

4

Thanks for the detailed explanation @David!
I see your point there. I will go ahead and request if this can be added to our webhook.
I’m not sure if it will be possible though, because on our Public API we have available now, and I know that field has additional complexity (because it requires some extra calculation), but its worth a try.

Another possible workaround I can think of is that when you receive the webhook you request available to the API, but this is probably not the best approach.
I will let you know as soon as I get a response in this.
Thanks again for the patience!
Tom

5

Hi @tomasw,

Yes, between posting this and getting your response I finally figured out that it is the available field that bumps an inventory request from a complexity of 1 to 31.

We’ve put in place what you suggested - making a call to get the full inventory when we receive a webhook. This obviously has two large drawbacks: (1) it’s silly :slight_smile: and (2) this occurs whenever we’re receiving a purchase order and at 31 complexity it eats up our allocation pretty quickly so we live in a throttled state for quite some time.

Of course, the long-term solution would be to reduce the complexity of calculating available so that it can be included, but I imagine there would be a lot of refactoring for that on your end.