Most CRM databases come with some sort of API these days, but organisations really need to understand what is in the API if they are to get real value and actually make the API connect their various systems. Here are a few pointers on what to look for in a CRM API
A) Types of web-service API. There are various types of web-services APIs and quite frankly if your CRM does not have a web-services API, the costs and risks of integrating to the cloud are going to be prohibitive. Here are the most common types on order of their usefulness
- REST (or RESTFUL) stands for representational state transfer, and is the most commonly used type of API used for web development because of its good performance in terms of fast performance, reliability and the ability to scale. It only works over HTTP, and you need to enforce security on top of this. Its best for mobile and social apps.
- SOAP (Simple Object Access Protocol) - only returns data in XML but works over any internet protocol. It is harder to implement than REST and consequently less popular with web developers. It is chatty (needs lots of bandwidth for communications). Security is an inherent part of the protocol and it performs better when processes require multiple calls. Best for payment gateways and telecomms.
- XML-RPC - this is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. Allows systems to pull information from your database.
- Web Hooks - "user-defined HTTP callbacks". These allow your CRM to post some information to another system when something happens (eg a product purchase is made).
B) Data Formats - ok so you have an API, but what does the data look like that is coming out of it, and how easy is this fro your developers to use and interpret?
- XML (extensible markup language) - ideal for highly structured information. Can take a fair amount of computing power and memory to validate data.
C) Single Sign and authentication - you are going to need other services or users to authenticate against your database in order to allow single sign on between (eg) your website and your CRM, or to allow other apps to speak to your CRM. Here is what to look out for:-
- HTTP basic authentication - simplest possible way to enforce access control as it doesn't require cookies, sessions or anything else. The username and password are not encrypted but encoded into one 64bit string. If the website does not use strong encryption with SSL, the passwords may be hacked. Least secure option.
- Cookies - need to use signed cookies for security. Does not work well with REST APIs
- Tokens (or JSON Web Tokens) - most commonly used by web developers.
- One Time Passwords - One-Time password algorithms generate a one-time password with a shared secret and either the current time or a counter - this allows you to leverage two factor authentication (most secure of the above methods)
- OAuth - an open standard for authorization, commonly used as a way for Internet users to log in to third party websites using their Google, Facebook, Microsoft, Twitter, One Network, etc. accounts without exposing their password. Works with HTTP and allows access tokens (see above) to be issued to clients. For web applications, look to be using OAuth 2.0 or higher.
D) Field coverage - ask your CRM vendor whether every field in your CRM database is exposed through the API for both reading and writing. This will give an indication of field coverage. Also ask whether those user defined tables you have created in your CRM so easily are also available through the API.
E) Process coverage - what basic processes does the API cover for Not-For-Profits. Processes are going to make integrating your core business transactions a whole lot easier. For example, is there a pre-configured process to:-
- Join as a member
- Make a donation
- Create a new contact with login credentials
- Add or edit an address and validate it
- Register for an event
- Create a transaction
F) Documentation - this is the main way in which your developers are going to learn about the API - the better this is, the faster the development will be - simple.
- Is it clean and well-organized?
- Are there enough details that developers need in order to be successful?
- Are there examples of what a request and response look like using various protocols?
- Does the vendor tell you what you can expect from them – how often do they update their API and how will they communicate changes?
- Is it interactive? Developers like to experiment and feed back to developer communities.
G) Upgrades and testing - How often do they update their API and is this upgraded when the CRM is upgraded? How are changes communicated? What is done to ensure your integration keeps working after an upgrade or a change to the API?
I) App store - The proof of the pudding! Always look at this to see just how many other developers have successfully integrated with your CRM. The more complex the integrations the better their API is likely to be.
Keeping the above in mind when evaluating a CRM API is one way to ensure that you get longevity out of your chosen solution. At Zentso, we have a very good handle on the APIs we work with. Ask us anything about them, our integrations or browse our products to see the proof of the pudding.