Updated on by Fraser Davidson
We deal with SaaS companies of all sizes from start-ups to established, newbies to ‘seasoned’. Would you believe SaaS has been around long enough now to have ‘seasoned’ operators?! So 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.
During some of our commercial conversations, we often reach an inflexion point where the process pauses. The client then goes off to build their API. Then 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 features that you build out should be heavily influenced by making your API play nicely. This means it can interact well with other applications it is going to be connected to. As well as meet user requirements and, moreover, 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’. As it is not complex and all it needs is a time-date database stamp on record creation. As well as 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.
Cyclr includes functionality to handle the mapping of custom fields. This means you can add a metadata endpoint to your API. As a result, it will allow for easier discovery of custom fields, 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 Webook endpoints to your API it is possible to automatically set and delete webhooks from a user’s account when integration is set up. This cuts 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 on your ‘Connector’. A connector is an interpretation of your API in the Cyclr environment. You can see our SaaS Connector Library for all our available connectors. 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 integration platform can help you build your API for purpose. As well as 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. With either your Alpha/Beta API itself or even using a database/google sheets connector as a proxy for your 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’ll provide you with some insights into the benefits of early iPaaS adoption for development purposes.
