Recommendations for Developers

  API2Cart just provides unified access for different shopping cart platforms. API2Cart doesn’t support stores’ high-level data operations (e.g., taxes calculation, order prices for some particular customer, etc.). You can develop business logic on your own or you can contact us for help. We always try to unify our API methods and their responses. Still, it is necessary to take into account the fact that because of some platforms’ various technical issues, it can be impossible to add the support of some methods or parameters. That is why, before beginning the integration process with any shopping cart platform, it is essential to see the list of the supported methods and methods’ parameters related to that specific platform. By default, API2Cart Interactive Docs is displayed in the context of all platforms. It means that all possible methods and their parameters are shown there. If you need to see the supported methods and parameters for the specific platform, you need to choose it from the drop-down list.

To test the work of each supported method for the specific platform fast, you can perform API requests directly from Swagger. For that, you need to indicate the appropriate API credentials by clicking on the button Authorize. If you don’t have the added store yet, you can authorize only api_key.

However, we recommend using Postman . It is the most convenient way of sending various API requests (the detailed info related to different HTTP request methods you can find here ). To send a request correctly, first, you need to check what HTTP method to use and how exactly to pass the parameters. For example, the product.list.json method needs a GET request, and parameters should be passed in a query string.

Methods that require POST requests can be divided into 2 types. The first type includes the methods that accept application/json in a raw_body, like, for example, product.add method.

The second type includes the methods that accept requests as application/x-www-form-urlencoded. These are any POST methods that are not requiring raw_body as application/json. For example, product.attribute.value.set.json. It is necessary to take into account that when passing parameters with content-type: application/x-www-form-urlencoded , they must be transformed into URL encoded format beforehand. If this is not done, then their meaning may be misinterpreted on our side. For example, during the transfer of the date and time in the parameters created_from/created_to, an unencoded date and time in ISO 8601 format look like this: “2020-03-27T11:01:18+0400”. Meanwhile, the encoded date and time look like this: “2020-03-27T11%3A01%3A18%2B0400”.  

About dates

The dates in API2Cart responses are displayed in the format ISO 8601. We display them with an offset corresponding to the current time zone of the store. Also, during the transfer of the dates in the parameters of our API methods, it doesn't matter in which time zone you send us the date, we will still convert it to the one required for a specific platform. You can transfer dates even in your timezone, but the date must be in ISO 8601 format, i.e., with a timezone offset. For example: "2022-09-11T00:12:40-0300" or “2022-09-10T23:12:40-0400“ dates are recorded with different offsets, but they both denote the same timestamp 1662865960.  

About the limits

By default, you are provided with 10 parallel API calls per account and you can do a max of 5 simultaneous API calls to 1 store. Please make sure that you do not send more API requests at the same time. If you still hit the limit and receive the error message please wait for at least one request to be completed. After it has been completed, you can run the next requests.  

About limits from the side of the stores

It is necessary to consider the type of store connection (bridge-based/API-based). API2Cart, on its side, continually optimizes the work of our API methods in order to be able to perform the minimum number of requests to the store. However, most of our API methods require performing multiple API requests to the store to form the response of our API method (the specific amount depends on the particular request and its parameters). This drawback is especially evident in API-based platforms. You need to take into account that API-based platforms have their own limits. For example, if to consider the Shopify platform (API-based platform), we can make 2 requests per second to the store. So if we receive multiple parallel requests to this store, they will compete for Shopify's API bandwidth. Therefore, considering the above, we do not recommend making heavy API requests in parallel (such as product.list, order.list, customer.list, etc.) to one API-based store. Bridge-based platforms do not have such limitations. But their speed depends on the specific capabilities of the server on which the store is hosted. Therefore, the decision on whether to make parallel requests to Bridge-based platforms should be made individually for each store based on the speed of response. In general, the response for Bridge-based platforms is formed much faster because we try to extract all the necessary information in one request to the store.  

Selecting the value of the count parameters

API2Cart makes it possible to extract a maximum of 250 elements in our list methods. Sometimes this value can be smaller for some API-based platforms due to technical limitations on the part of the platform. We recommend selecting values from 20 to 250 individually for each type of request and store. When selecting the count value, you should take into account the request execution time, the list of fields that will be in the response, and how long your application can wait for a response from API2Cart.

About response filtering

As we have already mentioned, most of our API methods require multiple API requests to the store to form a response. To reduce waiting time, use response field filtering to get only the data you need in the response. Outputting only necessary fields has the following advantages:

• Reduces the load on the store's server.
• Reduces request execution time.
• Ensures that request time does not increase if we add new fields to the response of a particular method.

The methods that can be filtered are those that return information about an object (the GET method is used when making an API request). These methods end in "list" or "info" (e.g., "order.list", "product.info," and so on). You can view a list of available methods for a specific platform using the "cart.methods" method or directly in the documentation. To filter the response, you need to specify the "response_fields" parameter. The value of the parameter is formed according to the response model of a specific API method. For example, for the "product.list" method, the value of the "response_fields" parameter may be as follows: {return_code,return_message,pagination,result{product{id,type,model,u_sku,name,description,price,manage_stock,images,product_options{id,name,option_items{id,name}}}}}

Example API request: "https://api.api2cart.com/v1.1/product.list.json?api_key=xxx&store_key=xxx&count=10&response_fields={return_code,return_message,pagination,result{product{id,type,model,u_sku,name,description,price,manage_stock,images,product_options{id,name,option_items{id,name}}}}}"

Example API response: The "response_fields" parameter supports filtering of any nesting level, except for the "additional_fields" and "custom_fields" field values, for which only first-level filtering is supported, for example: response_fields={result{product{id,additional_fields{tags}}}}  

About errors

It is mandatory to handle errors according to the API2Cart documentation that describes all the errors that API2Cart returns. It does not return any other error codes. You may sometimes see the request code = 12 in the API Logs section of your API2Cart account. It only appears there and means that the request has been queued or is running. After it has been completed, the server will return the data needed, and the code will disappear. Error code 107 is very common. This code includes uncategorized errors caused by store settings. For example, when a firewall is configured on the store that blocks requests.

In this case, you should ask the store owner to put on a whitelist a specific IP address.