Updated on by Fraser Davidson
We deal with SaaS companies of all sizes – start-up to established – newbies to ‘seasoned’ (yes SaaS has been around long enough now to have ‘seasoned’ operators).
It may be surprising to some but, even today, not all SaaS platforms have a fully formed API – some don’t even have an API at all…… and not just the early-stage SaaS companies either.
So during our commercial conversations we often reach an inflection point where the process pauses whilst the client ‘goes away to build their API’ so that they can then ‘get started with Cyclr’..
Logically they start on the premise that they should finish their API and then adopt the integration platform.
Yes and….. well……. no.
Building an API for Integration
The thing with an API is that how you build it should have a lot to do with how other applications are going to interface with it. The feature sets that you build-out should be heavily influenced by making your API ‘play nicely’ with the applications with which it is going to be connected to. To meet user requirements and, moreover, to be efficient.
Improved Record Retrieval Relevance
A simple example would be the creation of ‘Get New Records’ as an API method rather than just ‘Get Records’ – not complex and all it needs is a time-date database stamp on record creation and the ability to query on this basis. That alone can drastically reduce the API calls required to maintain an integration. Obvious perhaps when written down but this is the most common API deficiency we come across.
Dealing with Unknowns
Customisation is a key differentiator in SaaS. The trade-off of providing additional customisation options is that you’ll have a lot of custom fields to deal with when it comes to integration. This can quickly become a headache as no two integrations are the same.
While Cyclr includes functionality to handle mapping of custom fields, adding a metadata endpoint to your API will allow for easier discovery of custom field, effectively giving you a map of the unknown.
The Event of Triggers
While Webhooks are a great way to transfer data, or trigger integrations, between systems in a timely, event-driven manner, more often than not the steps a user has to take to get it up and running are overlooked.
By adding a Webook endpoints to your API it is possible to automatically set and delete webhooks from a user’s account when an integration is set up – cutting out any additional steps a user has to make to get the integration up and running.
Testing your nascent API in an iPaaS platform can help you fast-track your assessment of the API features you should build. You can prototype and test SaaS integrations rapidly and see where there are process inefficiencies/areas for improvement.
API Integration to Connector-based Integration
One of our roles as a business is to iterate your ‘Connector’ (a connector is an interpretation of your API in the Cyclr environment – see our SaaS Connector Library here) as you develop your API and your functionality. We understand that APIs evolve as the SaaS provider, and their customer base, evolves. Helping you expand your connectivity is what we are here for after all.
In short, early adoption of the iPaaS platform can help you build your API for purpose, contextual to user requirements and the requirements of other platforms. We encourage very early adoption of Cyclr so you can prototype from an early stage, either with your Alpha/Beta API itself or even using a database/google sheets connector as a proxy for you application to experiment with concepts. We price on the basis that you can ‘Start-Up’ and then evolve your usage as you learn.
Speak to one of our integration experts and we can provide you with some insight into the benefits of early iPaaS adoption for development purposes.