• Pages
  • /
  • Dealers
  • /
  • Data Depot
  • /
  • Version 4
  • /
  • Support
  • /
  • FAQ

Frequently Asked Questions

A list of questions that we get a lot and the answers that may help others benefit from.


A. We are happy to assist in making sure every dealer has access to our data through our API; however, as a business rule, we generally don’t assist with how to implement the data into a particular system. There are simply too many different databases, shopping carts, and other software environments for us to provide support for them all. A lot of dealers ask us how to import the provided data directly into their database and there just isn’t a simple process for that. There will always be some degree of integration code dealers will need to write to import our data into their database. The data format we use was not created to be conducive to any specific Database Management System (DBMS). Therefore in order to get the data into a particular system the first step is to request it from us, store it, parse it, and format it in a way that’s conducive to import into the particular database.
A. At this time, we do not provide any application or mechanism to consume our data. We’ve been asked numerous times if we could share examples or code snippets of how we built our sites and how we consume our own data. Unfortunately, our sites are fairly custom-built and don’t use standard off-the-shelf software. If we were to share our code, it probably wouldn’t help you much.
A. In the future we may provide a service or some kind of all-inclusive web solution that we can put in the hands of our dealers and let them run with it. But right now we merely provide the data; it is up to the individual dealers what they do with it.


A. Our API is designed to provide the necessary data for experienced programmers to consume, store, and integrate into their system. The data we provide are in a language-independent data-interchange format so that almost any programming language can be used to request and consume the data. The format we use is JSON which is not specific to any platform, programming language, or web system.
A. All timestamps are in the Coordinated Universal Time (UTC) +0000 UTC standard. UTC can be assumed on all dates that are returned from the API such as created_at and updated_at.

A. Recently it was brought to our attention that there may be some confusion regarding differing return types from the API. We'd like to take this opportunity to clarify some of the confusion and hopefully save you some time when dealing with the parsing of various responses.

The flexibility of being able to send multiple IDs separated by a comma with a GET request is nice, but it introduces two different data types of results. If you specify just one ID then you get a record {"data": {...}} but if there is more than one ID you get an array {"data": [{...}...{...}]}. This can make parsing into the right object difficult.

The thing to remember is the differing return types is a result of what you're actually returning, an entity or collection. Let's use some examples...

  1. All Attributekeys


    Returns {"data": [{...}...{...}]}, a multiple-entity collection response which makes sense to be an "array".
  2. One Attributekey


    Returns {"data": {...}}, a single entity response which makes sense to be an "object" and will never be an array. It wouldn't make sense to be an array with ever only one element.

  3. A set of Attributekeys filtered by the 'updated_at' date


    Returns {"data": [{...}...{...}]}, a multiple-entity collection response which makes sense to be an "array" because you are just filtering a collection by the `updated_at` date.

  4. A set of Attributekeys filtered by IDs


    Returns {"data": [{...}...{...}]}, a multiple-entity collection response which makes sense to be an "array" because you are just filtering a collection to those specific Id's.

    When you make the above request, what you are really doing is just a shortcut for...


    ...They both return the exact same thing.

    So, because our API is so flexible and there are so many ways to query the data, it is really just a matter of the type of response you'd like to receive. If you want to clearly separate the two return types, stick to standard entity responses where you can expect an object (ie. http://api.wps-inc.com/attributekeys/15), and collection requests that utilize "filter" where you can expect an array.

    The confusion lies in the tricky little helper where you can send multiple IDs separate by a comma (ie. http://api.wps-inc.com/attributekeys/15,17). That type of request is obviously throwing people off. We're even considering leaving that trick out of the documentation to avoid confusion. What you need to understand is that #2 and #4 in the above examples are not the same thing. They are two very different ways of querying the API.