Request Warehouse Location

GraphQL API
1

We have 3 warehouses in Ship Hero and we use automation rules to assign a location in Ship Hero based on the customers address and it’s proximity to the closest warehouse.

Because the warehouse is changing based on the automation rules, we need to know which warehouse the order was assigned to in Ship Hero.

To accomplish this, we’re doing a request call to look up all orders at each warehouse in Ship Hero, and checking to see if a specific orders was assigned to one of our 3 locations. This should always return only one warehouse, but we’re seeing a conflict due to there being 2 warehouses assigned with one order.

Details:
(warehouse_id: “V2FyZWhvdXNlOjc1NTUz” partner_order_id: “SO080898”) → GETTING RESULT | EXPECTED
(warehouse_id: “V2FyZWhvdXNlOjc1NzEz” partner_order_id: “SO080898”) → NOT GETTING RESULT | EXPECTED
(warehouse_id: “V2FyZWhvdXNlOjc1NzE0” partner_order_id: “SO080898”) → GETTING RESULT | NOT EXPECTED

Below is the call we’re making:

{“query”:“query { orders(warehouse_id: “V2FyZWhvdXNlOjc1NzE0” partner_order_id: “SO080898”) { request_id complexity data(first: 1) { edges { node { id order_number partner_order_id shop_name fulfillment_status line_items(first: 10) { edges { node { sku quantity quantity_allocated quantity_pending_fulfillment backorder_quantity promotion_discount } } } } } } }}”,“variables”:{}}

2

Hello @robbieshawn!
Welcome to the ShipHero Public API Community!

Let me see if I understood correctly. Do you poll each order to each warehouse to confirm which one is allocated to?

What were you expecting in the one in the middle? I receive an empty array as the order is not allocated to that WH.

Have a great day!
TomasFD

3

Hi Tomas,

Yes, you are correct about polling each order to each warehouse.

We were only expecting that it should give success or NOT EMPTY EDGE array for a SINGLE warehouse which it is allocated to. In our case, we’re getting NON EMPTY array for 2 warehouses which is causing confusion. The order should only be allocated to ONE SINGLE warehouse, not 2.

Can you explain why this order is showing allocated to 2 warehouses?

These are the 3 warehouse ID’s
V2FyZWhvdXNlOjc1NTUz
V2FyZWhvdXNlOjc1NzEz
V2FyZWhvdXNlOjc1NzE0

4

Hi Tomas, is there any update on this?

6

Hello @robbieshawn!

You are getting the order as allocated to 2 warehouses because of the field locked_to_warehouse. This field gets filled in as soon as the order comes in.

For getting that answer and not having to do 3 API calls, you could use the following query:

query {
  orders(partner_order_id: "SO081197") {
    request_id
    complexity
    data(first: 1) {
      edges {
        node {
          id
          order_number
          partner_order_id
          shop_name
          fulfillment_status
          line_items(first: 10) {
            edges {
              node {
                sku
                quantity
                quantity_allocated
                quantity_pending_fulfillment
                backorder_quantity
                promotion_discount
                warehouse
                warehouse_id
              }
            }
          }
        }
      }
    }
  }
}

You can poll the warehouse_id from the line_items to get the correct allocated warehouse when using Multi Warehouse Allocation rules.

Please let me know if this doesn’t help.

Have a great day!
TomasFD

7

Hi Tomas -

We followed your instructions, built the flow and yesterday we went live. We saw this strange issue:

Order:
https://app.shiphero.com/dashboard/orders/details/270508020

One of the line is fulfilled by TEXAS Warehouse while Other line is fulfilled by Hi Tomas -
We followed your instructions, build the flow and yesterday when we went live. We saw this strange issue.

Order:
https://app.shiphero.com/dashboard/orders/details/270508020
One of the line is fulfilled by TEXAS Warehouse while Other line is fulfilled by Pennsylvania
While in the Order response JSON, we see only TEXAS location is coming for both items.

Please advise how we can resolve this issue.

SH_wrong_WH_Lookup
SH_wrong_WH_Lookup1885×593 139 KB

{
“data”: {
“orders”: {
“request_id”: “6283c6b6a21d2c78d0a264bb”,
“complexity”: 11,
“data”: {
“edges”: [
{
“node”: {
“id”: “T3JkZXI6MjcwNTA4MDIw”,
“order_number”: “SO084023”,
“partner_order_id”: “SO084023”,
“shop_name”: “ISLE”,
“fulfillment_status”: “pending”,
“line_items”: {
“edges”: [
{
“node”: {
“sku”: “VY04-1106-AQNV-PKG”,
“quantity”: 1,
“quantity_allocated”: 1,
“quantity_pending_fulfillment”: 1,
“backorder_quantity”: 0,
“promotion_discount”: “0.00”,
“warehouse”: “Primary”,
“warehouse_id”: “V2FyZWhvdXNlOjc1NTUz”
}
},
{
“node”: {
“sku”: “ST04-1005-AQNV-PKG”,
“quantity”: 1,
“quantity_allocated”: 1,
“quantity_pending_fulfillment”: 1,
“backorder_quantity”: 0,
“promotion_discount”: “0.00”,
“warehouse”: “Primary”,
“warehouse_id”: “V2FyZWhvdXNlOjc1NTUz”
}
}
]
}
}
}
]
}
}
}
}
While in the Order response JSON, we see only TEXAS location is coming for both
{
“data”: {
“orders”: {
“request_id”: “6283c6b6a21d2c78d0a264bb”,
“complexity”: 11,
“data”: {
“edges”: [
{
“node”: {
“id”: “T3JkZXI6MjcwNTA4MDIw”,
“order_number”: “SO084023”,
“partner_order_id”: “SO084023”,
“shop_name”: “ISLE”,
“fulfillment_status”: “pending”,
“line_items”: {
“edges”: [
{
“node”: {
“sku”: “VY04-1106-AQNV-PKG”,
“quantity”: 1,
“quantity_allocated”: 1,
“quantity_pending_fulfillment”: 1,
“backorder_quantity”: 0,
“promotion_discount”: “0.00”,
“warehouse”: “Primary”,
“warehouse_id”: “V2FyZWhvdXNlOjc1NTUz”
}
},
{
“node”: {
“sku”: “ST04-1005-AQNV-PKG”,
“quantity”: 1,
“quantity_allocated”: 1,
“quantity_pending_fulfillment”: 1,
“backorder_quantity”: 0,
“promotion_discount”: “0.00”,
“warehouse”: “Primary”,
“warehouse_id”: “V2FyZWhvdXNlOjc1NTUz”
}
}
]
}
}
}
]
}
}
}
}

8

Hello @robbieshawn!

Since my last answer, we released an update to the orders query which better addresses the allocation information.

Please refer to this community post: UPDATE: Allocations field and Allocated Warehouse filter for Orders query

Kind regards,
TomasFD

9

Hi Tomas -

We designed our flow to fetch the allocated warehouse by sending (ORDER & WAREHOUSE Combination) in our REQUEST CALL which we changed as per your recommendation.

This was a major expense to us, but we redesigned to ensure it would work the way you suggested. Now, you are asking us to switch it to the old design we had prior to your suggestion. I’m sorry to say, but this would require us to completely rebuild the integration that we’ve been building for about 6 months.

Can you fix the current API issue to make it work with the old logic you suggested? Possibly have your developers add an “allocated_warehouse_id” field in this API. I’m sure we’re not the only ones who will benefit from this change. There are a lot of API users/ developers who need the data to be sorted at the order level rather than looking for all orders at a warehouse location. This becomes problematic due to the amount of calls needed for a single order that has multiple line items allocated to multiple warehouses.

Please let us know when and if this change can be made. We just went live which is what caused us to notice the change and new problems. This change from how you told us to design it is causing our orders to not be shipped, or to ship from the wrong warehouse. The only solution for this is to manually look at and approve individual orders, which can be time consuming and create a poor customer experience as well as many headaches.

10

Hello @robbieshawn!

Thanks for bringing this to our attention. I see your point and understand your concern.

I know that we have been proactive in communicating these changes in advance of the updates, but please allow me to connect with my development team to share your concern in good faith to our partnership.

Kind regards,
TomasFD

11

Hello @robbieshawn

Unfortunately, rolling back or adding that field won’t be possible.

The update from February was to address some of the concerns regarding allocations:

  1. The filter is not mandatory. You can still use any filter for the orders query or none at all.
  2. Allocations is a free field at the order level. It doesn’t add up to the cost of the query, which happened in the previous version, as it was required to poll each line item to get their allocated warehouse. However, it still returns the allocation for each line item no matter which warehouse it’s allocated to.
  3. In the case of MWA rules, where line items with the quantity ordered > 1 can be allocated from more than 1 warehouse, this Allocation field can return all of those allocations. In contrast, the previous version would only return 1 result.

I hope this helps you understand the nature of this update and its benefits.

Kind regards,
TomasFD