Hi Michael,

The way that the add-on has been built and the way it integrates with Snipcart means that there isn't a separate 'backend' or database table to store products, it's all done at the block level. This was an intentional decision, as the focus of this add-on is perhaps on simpler/smaller shops rather than big catalogue sized ones. There's nothing stopping someone from adding large numbers of product blocks by hand, but there's no direct mechanism to import them into a site.

With this integration Snipcart is handling all the cart and order processing side of things in the popup overlay that gets injected into your site. The API key is used to identify your site with Snipcart, but it doesn't really send information back and forth between your site and Snipcart - when you are adding something to the cart for example, you're actually communicating at that point with Snipcart, passing the details about the product through.

So in this case, all that the add-on is doing is providing an easy way to set up the Snipcart related scripts and configure product blocks/buttons, similar in a way perhaps to how Paypal buttons work (except you stay on your site). The add-on covers the product details and a few extra config options, while Snipcart is actually the order processing component.

Because Snipcart is being used as a service in this setup, that processing can't be moved to your own server. The trade-off is that it's very quick to set up a shop and you're not having to think about checkout screens, payments, etc, that's all handled by Snipcart, but on the other hand you are then not running the entire shop process yourself. If you are needing for whatever reason to control the entire shop system, you may need to use a completely integrated shopping cart.