I'm developing integration with magento. My client want to update his inventory via REST or API, the problem is that he has thousands of products and it will take a lot of time to update them one by one. I didn't found the way to update many inventory items neither from SOAP nor from REST. (For previous versions i used catalogInventoryStockItemMultiUpdate)
How to update a lot of inventory items in 1 call?
Related
our Shopify store syncs with NetSuite and we send orders with line items from Shopify to NS. However there are often situations where we need to enrich the orders in NS with zero value items that we don't want on the shopify order. E.g. marketing materials that we want to send out to the customer.
SuiteQL isn't an option as there is no way to add / update
SOAP API seems like a winner but good-god it's complicated
Could i build a complex rules engine in suite script that looks at the order and based on whatever it add line items?
any advice from someone who has done it before would be great?
You can use User-Event/Workflow or Map-Reduce/Scheduled/Mass-Update scripts which will filter orders, and update orders.
I have am trying to make a tool to manage inventory levels between my warehouse system and my bigcommerce store. The issue I am running into is the Bigcommerce only sets inventory levels based on the Ids/Variant Ids. My warehouse software only knows products by sku/subsku.
The first step in the process is getting the ids and variant ids and storing them for current use and later usage.
I do this by calling "catalog/products" and getting all the products for the catalog through a series of calls to build a complete list. I loop through and then do the same for the variants "catalog/products/{0}/variants"
With this list I match my skus and variants to the catalog list returned. Update the matching skus to big commerce id/variant ids for future and then finally I begin the process of actually updating inventory levels.
I then begin updating the product by calling the endpoint "catalog/products/{id}"
or
"catalog/products/{id}/variants/{variantId}"
This process takes way too long even for a few quantity level updates. Is there a better way?
I have also noticed that sometimes the big commerce ids will change for some skus. Which require a complete resync.
Are there better endpoints to use? Is there a way to update an item based on the sku not the id/variantid?
My solution is in C# but code is not the problem. The problem is what to call and if there is a better way to call the endpoints.
One area I see an opportunity to streamline the API calls is here:
I do this by calling "catalog/products" and getting all the products
for the catalog through a series of calls to build a complete list. I
loop through and then do the same for the variants
"catalog/products/{0}/variants"
You can get products along with their variants by including variants as a subresource using the ?include= param. For example:
catalog/products?include=variants
There would still need to be some kind of mapping from variantID to SKU, but when it comes to pushing the updated inventory to BigCommerce, we're also close to releasing updates that will allow you to batch update up to 50 products or variants in a single call. Keep an eye on our Changelog for that announcement: https://developer.bigcommerce.com/changelog
I'm trying to load all Skus from a Bigcommerce store. I first tried to use the API path /products/skus/count to get a count of the number of skus in the store as outlined in the BC documentation at https://developer.bigcommerce.com/api/stores/v2/products/skus However, the /products/skus/count endpoint is returning {"count":0}. I know for a fact that I have hundreds of products with a sku. Ultimately I'd like to get a list or array of just the skus in my store. Has anyone else been able to use this API or know a way to load all the skus in my store without loading all the product object graphs as that is too slow of a solution as I don't need all the additional information nor do I want to page through all my products since it's limited to 250 items at a time. All of my other API calls are working great so I'm questioning whether there is an issue with the specific API.
Are you try to get the "sku" property for all products or the SKU resource associated with a product?
The api call at the url that you've given https://developer.bigcommerce.com/api/stores/v2/products/skus
will return all the SKU resource/object associated with a product. You can either get skus for all products using the resource "products/skus/count" or a specific product using "products/{productid}/skus/count". Both calls works as documented.
I am using the Bigcommerce API to develop a small standalone application for a client. I store product information in a local database anytime I fetch products from Bigcommerce, to reduce latency and network load. However, products can change on Bigcommerce, and while it is acceptable for my application to show mildly outdated information, I will need to update my local cache at some point. My current plan is to do this by storing the original date I requested the product, after which I will need to perform another request to refresh the cache.
My question is, given a list of products (including their Bigcommerce IDs), is there a way to request updates to all of them through a single call to the Products Resource? I can make a request for each individual product by calling:
GET {api}/v2/products/{id}
I can also request all products within an unbroken ID range by calling:
GET {api}/v2/products?min_id={value}&max_id={value}
I am able to successfully call both of the above methods, and I can chain them together in loops to fetch all products. What I want to do is request multiple products with unrelated IDs in a single call. So, something like this:
//THIS IS NOT A REAL METHOD!
GET {api}/v2/products?id[]={value1}&id[]={value2}
Is there any way I can do this? Or is there another approach to solving this that I haven't considered? My main requirements are:
Minimal API requests. My application is small but my client's bigcommerce store is not, and I will be processing tens of thousands of products. I have limited CPU and network resources available, and I simply cannot process that many requests.
Scalable. As I said, my client's store is large, and growing. I need a solution whose overhead scales at a manageable rate with number of products.
Note: my application is a small web application written in PHP running on a Linux shared hosting environment. It is a back of house system which will likely only be used by single user at a time, during standard business hours. I haven't tagged the question with PHP because my question is about the API, which is language agnostic.
One approch can be.
First get all products from BigCommerce using simple products call.
Set some interval time to get updated product list.
You can use min_date_modified and max_date_modified OR min_date_created and max_date_created in products API call to get updated products details.
I've successfully got 3rd party merchant orders posting new orders to my client's BigCommerce store programmatically. I've even got product options posting as part of the order (product->option set-> option relationships are a total cluster).
My client relies heavily on configurable fields. I'm able to pull the definitions of the configurable fields for each product, but can't find a way to POST or update the configurable field values through the API.
Is it possible to manipulate an order's configurable fields through the API?
Got a response from the support team # BigCommerce. Manipulating configurable fields via the API is not currently possible and not currently on the roadmap.
Original reply below:
Unfortunately that is a product limitation with the API, it will not tie to configurable fields on the product. The best you can do is attach that information through a generic text field like 'staff_notes'. Honestly I have not heard of any talk of adding a way to add products with configurable fields to orders via the API. I think this may be because anything that can be done with configurable fields can be done with options and options are what is being pushed for the future. I have noted this feedback down though and will pass it along to our Product Manager for the API. Best case scenario is that it may be seen in a future version of the API which is at least several months away.