# Return the inventory-change id in API mutation responses?

**URL:** <https://community.shiphero.com/t/return-the-inventory-change-id-in-api-mutation-responses/3677>\
**Category:** GraphQL API\
**Created:** [April 27, 2026, 12:53pm UTC](https://community.shiphero.com/t/return-the-inventory-change-id-in-api-mutation-responses/3677 "2026-04-27T12:53:30Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![david](https://sea2.discourse-cdn.com/flex020/user_avatar/community.shiphero.com/david/32/22_2.png) [@david](https://community.shiphero.com/u/david)\
**Post date:** [April 27, 2026, 12:53pm UTC](https://community.shiphero.com/t/return-the-inventory-change-id-in-api-mutation-responses/3677/1 "2026-04-27T12:53:30Z")

</div>

When we call the `inventory_add` and `inventory_remove` GraphQL mutations, the response currently returns the updated warehouse product but not the id of the inventory change record that the mutation created. However, the `inventory-change` webhook payload does include `inventory_change_id`.

Could the mutation response be extended to include the same `inventory_change_id` (or `inventory_change_uuid`) that the resulting webhook will carry?

With that id returned synchronously, our webhook handler can recognize “this change was initiated by us” and skip re-applying it locally, eliminating a race where our API call and the resulting webhook both try to update our database. Today we have no reliable way to correlate a mutation with its own webhook, so we’re forced into compare-then-adjust semantics that are vulnerable to ordering bugs.

---

<div class="post-metadata">

**Author:** ![jjconti](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jjconti](https://community.shiphero.com/u/jjconti)\
**Post date:** [July 1, 2026, 5:15pm UTC](https://community.shiphero.com/t/return-the-inventory-change-id-in-api-mutation-responses/3677/2 "2026-07-01T17:15:55Z")

</div>

Hi David,

That makes sense. The inventory change record is created during the inventory\_add / inventory\_remove flow, but today the mutation response only exposes the updated warehouse\_product.

We’re going to create a ticket to expose the generated inventory change id(s) in the mutation response, so integrations can correlate their own API-triggered inventory changes with the subsequent inventory-change webhook.

Thanks for the clear use case.