Today the ability to integrate to best of breed applications like Content Management Systems (CMSs), Learning Management Systems (LMSs) and the like is critical to the delivery of member value.
Some AMS systems have light integrated versions of these systems but the modern association needs the flexibility to integrate to packages that have the ability to best meets their needs. That is where the AMS’s API comes front and center.
Think of the AMS as one part of a large “solar system” versus an overarching, do everything system. Integration to other systems is hugely important now and continues to grown in importance daily
-Sig VanDamme – Nimble AMS Founder
What is an API?
Think of your AMS’s API as a way for outside systems to communicate with the AMS.
What Can an API Do for an Association?
In the association world the API typically performs two functions; Single Sign On (SSO) and Data Exchange.
Single Sign On
An organization’s Association Management Software is really the authentication provider for your organization. If one wants to know if someone is a member they look in the AMS. Similarly when one goes to an association’s website and logs in, the CMS, behind the scenes, queries the AMS with the provided user information (typically username and password) and the AMS returns a token if the user is found along with the AMS Id of the user and perhaps some additional information (name, member type, etc). This enables the AMS to validate the user’s entry into members only areas as well as personalize the website to them. This authentication methodology between the association software and outside systems is commonly referred to as Single Sign On.
Single Sign On is an authentication process that permits a user to enter one name and password in order to access multiple applications
Often an outside application needs to access data from the AMS. For instance, the website content management system may need to display a member directory. To do this it needs to retrieve information from the AMS and it does this thru the API.
In addition, outside systems often need to safely write information to the AMS. For instance an association’s community package may write detailed or summary information back to the AMS that can then be used to calculate engagement.
What to look for in an API
An API needs to be easy, fast and well supported
– Noel Shatananda, Director of Solution Architecture – Nimble AMS
The API should be available in an easily digestible format, such as a web page with numerous working code examples.
The Salesforce API Documentation
does this really well.
The API must be well supported. This is multi faceted:
- To start there should be a status web page that shows the operational status of the system including the API. Salesforce does a great job with its trust site.
- There should be multiple ways contact the Software manufacturer for API support. For example Nimble AMS support can be accessed via phone, email, support form and the NimbleLand Community.
Ease of Use
Any reasonably technical administrator of the system should have the ability to easily setup the outbound and inbound data transfer information. This should not require a developer.
From the developer (i.e. non-setup) side of the equation we have found that RESTFul APIs are simpler to integrate with. It makes the testing process easier as well; testing the API can be done with a web browser and plug-in.
SOAP is a good second but it takes more works to get up and running and there always seem to be nuances to getting it to work right.
JSON Formatted Data
Ideally the API returns data in a JSON
Performance and Scalability
The API needs to be able to handle the expected transaction volumes or a lot of additional work will be necessary. Since Nimble AMS leverage the Salesforce platform
we do not run into the typical performance and scalability issues of legacy packages. For example yesterday Salesforce handled 3 billion (yes with a ‘B’) transactions and did each in an average of 212 milliseconds (real time salesforce performance).
Sometimes the systems we communicate with have very different performance envelopes and we have to write middleware to slow things down to a point the other system can handle it. This results in additional cost to the client so always keep in mind that marrying a high performance / high volume system with other systems that may not have the same performance.
The data stored in your Association Management System is truly the lifeblood of your organization and security needs to be a top priority when interfacing with other systems.
A good API will only grant access with the use of a security key that is known only to the authorized system. Remarkably we have often found services that were completely open.
Each system should have their own individual keys (I.e. do not give multiple outside systems the same security key). This will give your organization the ability to monitor and/or disable the use of the service from one vendor while continuing to allow the other.
A good API will also restrict what information is available once the service is accessed. As a best practice the minimum set of data and rights should be granted to the outside service. Just enough and nothing more.
Directly related to security is logging The API should have the ability to log access and what data has been sent and/or received. This should be easily configurable as it is often the case that during the initial phases of the implementation, a higher level of logging is required while a lower level would be required during regular operations post go live.
A business layer is the set of rules that the API should pass all incoming data through when interfacing with AMS. For example, the AMS may have layer for adding an event registration that rolls up 30 different low level interactions that are necessary to correctly add the registration into a simple layer.
Error Handling and Retry Capabilities
The API should have robust error handling and retry features to notify the external system of failures and retry gracefully after a failure.
Synchronous Versus Asynchronous Processing
Ideally the API should support both Synchronous and Asynchronous execution. When executing a task synchronously, the executing system must wait for the AMS to complete the task before moving on to something else.
When executing a task asynchronously the external system can submit the task to the AMS and move on to another task before it completes. In this scenario the API needs to provide the calling system with either a callback or another form of notification. Asynchronous tasks are typically used for large, bulk data transfers that may lead to inordinate wait times on the calling system if it were processed synchronously.
It is very important that every API support the concept of limits. This helps to balance the use of system resources and ensures that no one process ends up consuming all the resources.
The Rise of the API is Great for Associations
APIs sound dull, but they’re anything but. They are a valuable tool in an Association’s Race for Relevance
and can fundamentally change the way value is delivered to members.