Is there a recommended method (API or Notifications) for gathering order information (ended auctions or listings)?
Using the notifications seems inconsistent, based off listing type (different notifications for different types) as well as I've read that the notifications are asynchronous and batch driven, making it difficult to decide where to put logic, at times, since messages are coming in different orders (potentially).
I'm beginning to think that the pro-active route maybe the right way to go, in other words, using the API to make requests to get the order information, rather than waiting for ebay to send the notifications
Hope this is a clear question, let me know if not.
-D
Posts:
1,253
Member Since:
2/17/07
Re: API verses Notifications Recommendations?
Posted:
Nov 7, 2009 12:57 PM
Most of the people who rely on notifications are trying to achieve the following:
1) 'Real-time' operations like synchronizing inventory with other systems or sending e-mail to buyers.
2) Minimizing API calls since notification do not count in the daily limit.
This group of people comes crying to the forums every time notifications break.
I see the following problems:
1) eBay makes no latency guarantees, and historically, some notifications are never sent.
2) Since notifications are asynchronous, you can get blasted by the eBay server. If your own server or backend processes can't keep up, the notifications are no longer real-time. In theory, eBay will continue to retry, but that may just make things worse. Even if you catch all notifications on the first attempt, you still can't act on them immediately because production apps are not supposed to make more than 18 concurrent API calls. You may also create race-conditions with your other procedural code. Realistically, you need to queue the notifications for throttled synchronous processing along with all other API calls.
What many people fail to realize is that most Trading API calls can return up to 200 records. GetSellerEvents can return up to 3000 records per call. As long as you maintain your own time baselines, polling can still be very efficient. You also need to be tracking status in your own local database so that you can determine exactly what has changed.
