POS 101: API Integrations
Ever since the emergence of cloud technology, the point of sale industry has made an increasingly aggressive push toward centralization. This has largely involved the utilization of integrations between two or more systems. Your point of sale vendor would love to be able to provide you with an all-in-one solution that meets all of your business needs, but this is simply not realistic. So, to benefit everyone involved, different software providers have started teaming up.
Vend (see our review) is an excellent point of sale system, but it doesn’t have the functionality necessary to handle all the accounting-related needs of an average business. Therefore, a partnership with Xero (see our review) is cultivated so that the two companies can use one another’s APIs to build a digital bridge between them. The end result is that the merchant now has access to an even more comprehensive tool, and both Vend and Xero enjoy a piece of his business. Everyone’s happy!
That is unless you really need to connect your Bindo POS (see our review) with your MailChimp (see our review) account, but there’s no integration to be found. You could build you own integration so long as both companies offer a public API, but this may not be the best way to go. I’ll get into that later, though. First, let’s learn a little more about API.
Table of Contents
Application Program Interface
What the what now?
Yep, that’s what API stands for. Doesn’t really clarify much, does it? Well, as is true of every other aspect of the English language, “application program interface” makes this concept sound more complicated than it really is.
Essentially, an API is “a set of routines, protocols, and tools” that allow programmers to build connections between two or more software interfaces. These connections, or integrations, are what allow applications to communicate and trade data. Depending on the sophistication and overall function of the integration, they can be one-way (only sending information from one side to the other) or they can be two-way (where information is traded between systems).
In either case, there are essentially two methods of integrating one software interface (your point of sale system, in this cas) with another (CRM, accounting, eCommerce, etc.): a prefab integration or a custom integration.
Prefabricated (prefab) is one of those words you might see thrown around in our reviews. Basically, it’s a word that we stole from the construction industry to indicate anything that has been fabricated to standard specifications, as opposed to building something to unique specifications. Prefab integrations are the connections POS vendors build between their own software and that of a third party. It’s the connection between Quetzal and Shopify or Revel Systems and QuickBooks or basically any other integration that comes standard (prefabricated) and you don’t have to build yourself.
Prefab integrations may or may not come at an extra cost. You’ll have to pay for the service itself—third party software comes with a subscription cost or one-time fee just as POS software does—but depending on your POS vendor, you might be charged extra for the integration itself. This is justifiable considering how much it costs to build and maintain just one integration (something I’ll break down in the next section).
Custom integrations, as you’ve probably deduced by now, are those you (or the web developer you hire) build yourself. This process requires access to both APIs: your POS vendor’s and that of whichever external software you’re integrating with. Not all companies allow access to their APIs, and those that do will generally charge some kind of fee for access. This is something you’ll want to factor into the overall cost of a custom integration.
David Honan wrote an excellent article breaking down all the expenses that go into creating your own integration. I’d encourage you to read it for a more complete picture, but the gist of it is that it can take around seven weeks to create just a single integration; with the standard rate for a web developer hovering around $60 per hour, you’re looking at a several thousand dollar investment. Not to mention, you’ll need to budget “25-30% of the original development cost for ongoing maintenance.”
Which is Better?
Custom integrations afford merchants more freedom since they get to design the connection to their exact specifications. However, this comes at a substantial cost, especially compared to prefab integrations. There’s also no way to guarantee it’s going to be a smooth, fully-functional integration, and you’ll have to keep pouring money into it to make sure it stays functional. Then again, you’ll have the integration you need, and if it opens up a good influx of cash it could very well be worth it.
Prefab integrations are more limited in that you don’t really have any say in how the systems communicate with each other. If it’s not the most effective or efficient method for your business, there’s not much you can do about it. Of course, it is much cheaper, and you can do your own research beforehand to make sure the integration is up to par.
Really, both avenues have their pros and cons. Prefab may be cheaper upfront, but if you create an integration that proves lucrative, you could see a big enough revenue increase to make it worthwhile. On the other hand, even if the integration you want isn’t available right now, POS vendors are creating new ones every day. If your desired integration is already in the pipelines and you can afford to wait a couple months it might be wiser to do that. The moral is that there is no hard and fast rule for prefab versus custom integrations. It’s going to depend on your business’s needs and what you can afford to spend to meet those needs.
Though we certainly won’t be able to provide all the answers, if you’re feeling a little overwhelmed by all this API talk, feel free to drop us a line. Maybe we can provide a little more clarity on the subject.