Skip to main content
No Status

Merged orders results in an inactive order that is not reachable via API

Related products:Orders & Shipment Management
  • April 25, 2019
  • 8 replies
  • 45 views

When you merge 2 orders, one order ends up inactive. The surviving order has a advancedOptions.mergedIds array with order IDs that are not reachable. Asking for them gives you a 404. There should be a way to query an inactive order.

8 replies

Definitely a problem for us in our office. That merged order now becomes a ghost.

Definitely a problem for me. The merged order becomes a ghost, even if I need to access the information after the fact. There are times when I need to determine what order is now the parent to this order.

  • October 1, 2020
Including inactive orders in API responses would be very useful when fetching recently updated - to see that an order has been made inactive is more convenient than it apparently vanishing, as far as the API is concerned.

  • November 6, 2020
Not being able to access the 'orderNumber' of orders that have been merged is an issue for us. Unfortunately have the merged 'orderId' is not enough to clean up order data on our side.

Moderator-Davis
No text available

  • August 2, 2024

Was there every a solution for this? I still can't find anything with a merged ID.


CaraAdmin
  • Community Manager
  • August 16, 2024

Hello, @dbminting!

 

Thank you for your post! I understand how important this is to you. I reached out to a few folks, and they recommend contacting apisupport@shipstation.com. They’ll be able to assist you further. 

 

Happy Shipping!

 

-Cara

 


SJE-inventory

+1 on this. Still an issue in 2026, confirmed via API support that it's expected behavior.
For context on why these matters: we reconcile ShipStation orders against our ERP weekly, and our middleware also polls the API multiple times a day for order syncing. But no matter how frequently either system checks, once an order is merged via Combine Shipments, its data is gone for good unless someone happened to capture it before the merge. Polling more often doesn't help; the data loss is structural, not a timing issue. This means any order merged before we had a chance to record its identity is permanently unrecoverable. There's no way to backfill it after the fact, even though advancedOptions.mergedIds on the surviving order still references it. Even a minimal fix would help a lot: just returning the original order number for a merged-away orderId (instead of a 404) would let API consumers reconstruct historical merge relationships without needing to pre-cache every order "just in case."

Would really appreciate this getting picked up. It's been 7 years and still NO STATUS on something that seems like a small API change.