Find the answer to your question
This article will give you some best practices to implementing the GetOrders API request. It will ensure that your GetOrders requests run smoothly and will give your system the best chance to function even if there are bugs in your code or within eBay.
- The first thing you will want to do, is follow the recommendations from this article, https://ebaydts.com/eBayKBDetails?KBid=1788
Once you have the basic concepts in place, you can now start to think outside the box. What happens if the eBay API has a bug? What happens if my system has an outage? Here are a few best practices you can follow,
1. You will want to account for 'duplicate' orders. Every once in a while you might see an order come back in the response multiple times for a different time range. This can happen for a few reasons, but we don't need to get into that now. Usually if you see an order come back, and it is completed and paid for, you will fulfill that order and ship it. So it is good practice to keep all OrderID's you have fulfilled in your own database. That way if the OrderID comes back again in the response at a later time, you can set some sort of alert to see why it might be showing up again.
2. Save the Create/Mod Time from your last request. Just in case you have an application that gets interrupted for whatever reason, it is good practice to know what the last time range you returned successful is. Meaning if you are using ModTime, and you asked for the following time range,
You want to save that in a local database. That way if the request fails, or a user's machine has an outage, or etc, you know where you left off with your last GetOrders time range. And when all systems are back up, you can start from the appropriate time range. This is very important because as long as you never have any gaps in your time range, eBay will always return all the orders that need to be processed.
3. Incorrect Create or Mod times. So when looking through your orders being returned, you might see the Create or Mod time for an order has been changed. The CreatedTime should never change. But if an order has at all been modified, by the buyer or seller, the LastModifiedTime will change. Also over time eBay has had some known Tcache issues where we incorrectly change the Create or Mod time of an order. Which will cause it to surface again in a later responses. As long as you have #1 in place above, these orders can be ignored. If you do see this, please report this bug to us, http://developer.ebay.com/support/developersupport/default.aspx.
4. Orders showing up in the response with Create or Mod times outside the range you specified. Another issue you may see from time to time, is an order or orders coming back in the response with Create or Mod times outside the time range you have asked for in your request. Again, as long as you have #1 in place above, these orders will get ignored. But again if you see this, please report this to us, http://developer.ebay.com/support/developersupport/default.aspx.
Again note that as long as you don't have any gaps in your time ranges, no matter what kind of results are sent back to you, you should always get back all the orders (and in some cases orders you have already fulfilled).
Q. How do I know if an order has been paid for?
A. If an order is completed and paid for, you will see the <PaidTime> output present in the response.
Q. How do I know if an order has been shipped?
A. If an order has been shipped, you will see the <ShippedTime> output present in the response. This field will only show up if the seller marks the order as shipping through the API or UI.
- Using the PaidTime and ShippedTime is a good way of checking if an order is 'complete' and/or 'fulfilled' already.