Access to the API is provided by the HTTP-requests and implemented using the principles of REST. Basic URI for web-service is:

The exchange is performed in the UTF-8 encoding.
For debugging you can use a Google Chrome extension Advanced REST Client.

Request

Requests for receiving and recording data performed using HTTP GET and POST methods, respectively. There is the concept of operations in service structure. The operation is indicated as the path in the URL. Parameters are passed as a query string HTTP (GET) or POST data. Most of the operations perform on behalf of a specific user and requires authentication using parameters userlogin (user login in the system) and userpsw (md5-hash of user password in the system). Md5-hash can be generated by programming function (most programming languages have this feature), or use the online-generator (eg, md5x). Every operation may have a list of additional parameters defined by the context. For example, request operation "Search items by number" could be as follows:

When using the POST method in HTTP-Content-Type header to be transmitted media data type of query application / x-www-form-urlencoded and according to the type of body from the HTTP-request. It's nesessary to transmit media-type of request data in HTTP-header Content-Type when using POST method and it needs to generate the body of HTTP-request with this media-type.

The HTTP-header Accept needs to transmit the expected type of response data. Currently implemented only JSON type and, in any case, it will be returned. However, in developing it's necessary to take into account the specified feature and transmit Accept header with a value application/json.

Response

In case of successful execution of the operation the web service returns a response with HTTP-200 code and the response body in JSON. The format of the response is determined by each operation. Example of a successful request:

{
 "brand": "MERCEDES-BENZ",
 "number": "A1130940048",
 "short_number": "1130940048",
 "outer_number": "A 113 094 00 48",
 "properties": {
  "weight": "0.248",
  "descr": "Mass Air Flow Sensor"
 },
 "images": [
  {
   "name": "00296fd49ba2b385e441829fc0b2913ea6.jpeg",
   "order": 0
  }
 ],
 "is_skipped_image": false,
 "images_count": 1,
 "rating": 112,
 "rating_4mycar": 88,
 "crosses": [
  {
   "brand": "ASHUKI",
   "number": "116617A",
   "numberFix": "116617A"
  },
  {
   "brand": "BBT",
   "number": "AMS405",
   "numberFix": "AMS405"
  }
 ]
}

Response with HTTP-code 400 and more is an error. The response body contains an error code and, as a rule, a text message describing the causes of the errors in JSON. An example of an error message:

  { 
    "errorCode": 102,
    "errorMessage": "User Authentication Error"
  }

To organize a quality search for auto parts on your resource, it is recommended to use four API functions:

Recommended search algorithm in your service with the participation of built-in API function

Note the feature of forming the first stage of search using the search/brands function. The essence is that you add to the first stage of search those products that can lead (directly or through cross-references) to the products you can sell. Naturally, some products may potentially be absent in your product offer, so clicking on some lines may lead to an empty result. And in the case of low demand coverage by your assortment, such cases can lead to the customer's departure. To avoid this, you can "look into the future" for each product from the first stage of the search in advance to find out "if there will be anything available" and exclude lines without availability. On the other hand, in this case, you will lose the opportunity to collect unsatisfied demand (if you collect and use it) and create additional load on your database with additional requests.