I’m looking for answers regarding Shopify and Navision. We are considering switching our current webshop host to Shopify.
How ever – one important thing is, that we can make Shopify work directly with our accounting system – Navison (now Microsoft Dynamics NAV). This must be possible, but how comprehensive (and pricey) is this integration and does any of you have any experience in this field?
Any help would be much appreciated. Thanks!
Since I don't have enough points to post a comment I'm posting this as an answer.
I'm really sorry to have to post such a negative comment like this, especially since I may need help from Shopify dev suport at some point and I really don't want to piss them off, so hopefully they won't take this personally.
I can appreciate some of the design decisions Shopify has made with its APIs, but David Lazar and crew seem to be missing Jarko's point or just don't care.
I personally could care less about SOAP, I use JSON and REST for everything whenever possible and am pretty agnostic when it comes to technology stacks, but I too am disgusted by the limitations of the Shopify product API (and other parts of the API), which, at first glance looks half way decent until you start trying to use it for any heavy lifting.
Virtually every other similar API I've worked with allows devs to create multiple products with a single API call, in fact this is the first API I've ever had to use that didn't offer that ability.
Considering how slow the Shopify API is at creating a single product with variants and images, it's a wonder there's anyone at all using it to manage more than a handful of products. For example, I spent the better part of 2 days waiting for my script to finish creating all our products via the API due to the 1 products per call limitation.
My API library is designed to respect the API request limits, but we never even get close to the limits because it takes between 11 and 20 seconds to create a single product with variants and images. I have roughly 8000 products to upload. Do the math. For people used to working with true enterprise level APIs that can handle thousands of products per API call (AmazonMWS is a perfect example), waiting 2 days for products to finish being created is just crazy, and god forbid you need to do something as simple as reorder the products once they are uploaded.
In that case you get to make another 8000+ api calls to delete all the products (which takes a little over an hour) and then start the upload process all over again and wait 2 days. That's about as inefficient a system as I can imagine. I've tried doing bulk CSV uploads to work around these problems, but guess what? The bulk upload can't handle a CSV file bigger than a couple of megabytes and to reference bulk-uploaded products via the API in future API calls you have to specify a shopify product ID which means that after bulk uploading them, you then have to pull down a list of all the product ids and variant ids and feed that info into your database so you can then reference them by shopify's internal ids instead of some kind of parentid or sku set by the merchant.
All in all, it's a total nightmare to deal with. By contrast it takes about an hour for me to upload and process a full product feed via Amazon's API, including 6000+ parent products with 60,000+ child variants and 60,000+ images. Amazon's API is annoying for different reasons (it takes 5 separate feed formats to upload all the product info and their documentation could make a grown man cry), but at least it's generally fast and capable of processing thousands of products in under an hour.
Amazon’s API also provides mechanisms for bulk updating prices and inventory quantities and updating product data by a merchant-defined identifier such as an SKU which means that it takes about 5 minutes for Amazon to update quantities and prices for my entire inventory without any of the hassles of mapping ids back to products in our internal systems just to be able to reference them 1 at a time.
Also, the fact that there's no way to tell the Shopify product API to replace a product with a duplicate handle instead of creating a new one means that if my script times out or the API chokes due to a communication error (or like today when the API mysteriously began return 404 errors for several hours) and I have to restart multiple times, I end up getting duplicate products which are then very annoyingly difficult to track down and eliminate.
All of this together makes for a miserable experience for anyone who has to manage more than a few hundred products via the Shopify api. Telling developers that it's their own fault for not wanting to jump through all these hoops indicates that Shopify devs are either lazy or just totally out of touch with how developers need to use the API.
Were I not already 3 weeks into my 2-week integration and theoretically just hours away from launching a new site I would be ditching Shopify at this point. This project is now more than a week overdue entirely because of how cumbersome the product API makes managing large numbers of products. And forcing users to come to Stackoverflow to post API questions where they can't even comment without having a certain reputation score....I could go on and on. Don't even get me started about the lack of a discount/promotion api, or the inability to create users via the API that can log in without an admin manually going to the shopify backend and clicking a link for every user they want to activate.
Every time I think I'm going to be able to get something done with this API it turns out the be a clusterf$%*!. But hey, it MUST be an awesome API because it's all done in Ruby using REST principles...oh goody! Sigh. I'll take an ancient SOAP based api over this any day, but it's too late for me to ditch this project and start over now. Double sigh.
One thing to keep in mind is NAV 2013 is right around the corner. This release includes support for Odata which will likely make the Shopify integration substantially easier since JSON will be the common data format. However, all of the various details involved in full-circle sales transactions ensure such an integration into an ERP system (not just NAV) is going to be a significant effort. Be prepared to see some expensive quotes from your NAV partner unless your needs are extremely narrow.
Looking at the API documentation for Shopify, it appears it would be quite straight forward to synchronize data between NAV and Shopify. In NAV, there is no built in way to work with the Shopify API, instead NAV offers only the building blocks for generalized integration with other systems. So you will need to get a quote from an NAV partner to determine the cost for them to write the integration.
The cost will depend on how many entities you need to synchronize between the two systems, and which version of NAV you are using. If you are on NAV 2009 R2 (the newest release), the partner can write .NET code which runs in the NAV server to call Shopify directly. If you are using an earlier version, the partner would need to use COM or CFront instead, which is a little more work.
My 2 cents is that when I tried to integrate Shopify to Navision I ran into the fact that it requires SOAP. If you have no experience with SOAP, consider yourself lucky. It is an expression in how not to do Internet Computing in an elegant fashion. It is confined to proprietary Enterprise systems, no surprise there, like Microsoft sells. No one else would bother supporting that software poo.
As long as you toil with .Net C# or Java and have experience with SOAP, bridging Shopify to Navision is likely a simple task. For anyone else that works with the modern Internet using HTTP to transfer data as XML or JSON, the transition to SOAP should be reason enough to run away screaming. Again, just my 2 cents.
