Find the answer to your question
Can I get a quick overview of LMS?
What is eBay's Large Merchant Services (LMS)?
eBay's Large Merchant Services make it possible for a Seller's application to send very large amounts of inventory to the eBay site, and to download order and transaction information. These services have been designed to make a large merchant's workflow more efficient by making large file transfers faster on the eBay servers.
Why should I consider using LMS if I am a large seller?
eBay's Large Merchant Services provide the large seller the following advantages:
What APIs are a part of LMS?
Large Merchant Services is a solution that consists of three separate APIs:
1. Merchant Data API (data file)
2. Bulk Data Exchange API (web service)
3. File Transfer API (web service)
Can I use any of the Shopping or Trading API calls with LMS?
You can use some Trading API calls with LMS. See the Related Calls section on this page -
Can I get a quick overview of each of the APIs?
Merchant Data API (data file)
This API defines the data that can be passed to and from the eBay servers in files. This is the information about your inventory (to manage items and get report data about your inventory). The calls that are used in the data file cannot be used to make direct API calls (without a data file) to the eBay servers.
Bulk Data Exchange API (web service)
This API describes how to manage the Large Merchant workflow, such as starting, stopping, and checking the status of data processing. Because we are processing such large amounts of data, the eBay servers process the data files asynchronously, which means you can download responses when the processing is done. Pre-defined reports are call responses that contain inventory management information, such as sold items and active inventory.
File Transfer API (web service)
This API service passes the data file to and from the eBay servers.
The Large Merchant Services APIs work similarly to other eBay APIs. For example, the Bulk Data Exchange API, and the File Transfer Service API use the same authentication as the Trading API. You can use the same AppID for these APIs as well.
However, like the Merchandising API, the Large Merchant Services APIs are built on eBay's Services Oriented Architecture (SOA) framework. As a result, there are some changes to the API conventions and how you route requests.
Another difference is that the Large Merchant Services API uses the File Transfer Service to upload or download attachments.
The Large Merchant Services APIs support the HTTP POST method and both SOAP and XML formats.
eBay developers start out with a default request limit. You can increase your request limit by applying for a Compatible Application Check. API call limit information can be found here - http://developer.ebay.com/products/overview/call-limits/
In order to improve your testing efficiency, we have included the following best practices steps: practices:
We strongly recommend using the eBay Developer Sandbox testing environment before putting a Large Merchant Services application into production.
The call limits for the Sandbox environment are higher than the limits in the Production environment. Therefore, you can make more calls in the testing phase of your development than you can in production. This is because you may need to make a call, get an error, revise your call and iterate through this process several times before you have your calls working the way you want them.
The Sandbox gives you enough calls to do extensive testing while still protecting eBay assets. File a service request with eBay's Developer Technical Support team if you encounter a sandbox limit impeding development.
Large Merchant Services is an integrated solution. To test your ability to add, revise, relist, or end item listings, you must use all three APIs together. That is, you cannot test the File Transfer API for uploading a file without first creating an upload job with the Bulk Data Exchange API and building a valid data file with the Merchant Data API or Trading API.
All three APIs are supported in the Sandbox environment, which should be used for testing. In the Sandbox environment, an application can perform the same operations it would in the Production environment, except that the users, items, and payments are just test data. The test data cannot be accessed from, or used in, the Production environment.
The following tables list some of the errors (and remedies for those errors) that beginners may receive:
Invalid authorization token
Make sure you are using the correct endpoint for the auth token (Sandbox or Production)
UUID is requred (but there is a UUID in the request)
Make sure you have SOAP11 or SOAP12 specified as the MESSAGE PROTOCOL in your header.
UUID is not unique
You will see a message like this if you try to make the same call twice. Modify the UUIDs and SKUs if you want to test uploading the same data file more than once.
UUID is not valid
Try using a UUID generator to get a unique number. Enter the number just as it was generated - including the dashes. The UUID can contain both numbers and the letters a-f. It cannot be more than 33 characters long.
Maximum of one job per job-type in non-terminated state is allowed
You can either abort the jobs in the CREATED state to start afresh or use the existing jobs to upload files and schedule the jobs. For jobs that are already being processed, you will need to wait for them to finish before you can submit a new job of that type.
· Sandbox Gateway URL (endpoint): h
· Production Gateway URL (endpoint):
File Transfer API -
· Sandbox Gateway URL (endpoint):
· Production Gateway URL (endpoint):