ERPs (Enterprise Resource Planning [software]) come in many forms, styles, and flavours. Onsite, cloud based, multi-site, ERPs exist to fit every niche and need of many industries. But no enterprise software can do 100% of what a company needs. It’s not uncommon for a company to have customizations, or external applications made to integrate with an ERP. Automation and reporting are the two big uses. As a developer, the APIs these ERPs provide can be wildly different to work with. At the end of the day, they all more or less will work, they just require differing amounts of time and cause different kinds of headaches. But that won’t stop me from ranking them:

The Best- REST or SOAP

Cloud-Based ERPs, such as Netsuite, Sage X3, or Exact Online are becoming all the rage. They’re easier to implement, require zero on-site infrastructure, and offer low upfront costs. It’s no wonder old-school players are slowly switching to cloud offerings.

They are all joined by a set standards. Web Services commonly follow either REST or SOAP standards, with SOAP being the more strict of the two. Web service standards add a layer of consistency to interacting with them. The wheel isn’t being reinvented with each API. Along with this, other standards such as OAuth further simplify the integration process.

Standardizations take a lot of the guesswork out of creating an integration. SOAP (or REST) based web service APIs will be quicker to develop than other integrations, with less roadblocks or “development by trial and error”. It’s also pretty common for cloud based APIs to have good documentation, a trend for the betterment of the world.

REST and SOAP APIs are not without their flaws, there are still a few drawbacks that need to be considered or even developed around:

API Limits - Cloud services cost money to run, so it is very common to put a limit on the API by setting a cap on the number of requests in a given hour or day. Under normal use, this might not be an issue, but a bigger company might have to shell out for those extra API calls.

Speed - Adding distance between the user and the server slows down their connection. A cloud based ERP is never going to be faster than a good local implementation. This speed drop can fall anywhere between unnoticeable and unusable.

Sandbox Options - Cloud solutions prevent users from poking around critical parts of the system, which is good, but it also makes life as a developer more difficult. With most cloud solutions, you have no control over backups or databases. It’s fine until you accidentally create 10,000 sales orders with a buggy script, and you now need a new script to reverse it.

The Good - Client Integration

Prior to the rise of Cloud Solutions, every ERP was accessed through some kind of client; a desktop application specific to the ERP. Not every client offers an API, and the ones that do can have wildly different functionality. Clients can scale between “Worse than a direct database” and “As good as web services”. A client gives a certain predictability and stability to actions, at the cost of speed, error handling, and flexibility. A client may provide you a “search” function, but you have no control over how efficient that search will be done.

Two factors are front and center when it comes to the quality of a client’s API:

Validation of Data - In general, a web service doesn’t allow you to make a muck of the system, and ideally a client shouldn’t either. Validating API calls are a good practice to make integrations smoother. Expecting a developer to not put bad data into an API is like expecting a toddler to not spill a glass of juice. It’s possible, but nobody's perfect.

Authentication - Client APIs should be as secure as the client themselves. A best practice is to allow the use of the client login screen with the API, keeping integrations consistent with the client. When the only option is to pass through the username and password as plain text into the API, you will certainly have developers store those credentials in plain text.

The Bad - A Direct Database or Undocumented

It’s an exaggeration to say “Bad”, but they can certainly be unpleasant to work with. Direct database access isn’t necessarily a problem, SQL can validate data, and provide secure authentication methods. The gotcha is that these types of integrations are commonly accompanied by zero documentation.

Your development process is no longer “agile”, it’s a treasure hunt. A salaried developer might find it enjoyable prying apart the forbidden inner workings, but management won’t be happy when two week sprints turn into two year marathons. Direct database integration leave room for bad things to happen, and not knowing how things work compound the fear behind this. It’s possible to insert or delete data that breaks the entire ERP. If you ever find yourself in this situation; make frequent backups, document your process, and send for help.

These kinds of integrations aren’t all bad, there are some benefits, but they don’t outweigh the grievances.

Speed - A well implemented direct database connection on a local network can be incredibly fast. An API tool over web service could take 3 minutes in a place where a direct database connection took 3 seconds.

Job Security - If you’ve created an integration to an obscure API with zero documentation, you likely have business critical knowledge that cannot be replaced. Make sure not to write any of it down, that would only serve to help colleagues and future generations.