Updated on by Daniel Twigg
A lot of our conversations with potential Cyclr customers centres around APIs. This is because APIs present many possibilities and how our data orchestration tools abstract the complexity of dealing with them.
But not all use cases require your app to have an API.
Power Integrations with Data Export Operations
Cyclr successfully powers integrations of various types where no API exists in the host platform. It can do so via simple data export operations. These are a great example of either one-off bulk exports of regularly scheduled tasks.
Mapping data to fields in any of the 400+ SaaS apps we have in our library is a straightforward task for Cyclr. As a result, you can send the data your users wish to export to an HTTP endpoint.
Data Import Integrations
On the other hand, data import can work in a similar fashion. Whether you’re giving your users the ability to import data from a system they are migrating away from. Or providing a way for ad hoc data to be sucked in. Cyclr has a number of ways to avoid the need for a formal API.
At an infrastructure level, our suite of database connectors can be used to import data directly into your app’s datastore. Alternatively, if you have the ability to open a simple HTTP listener – an API-lite, if you will – Cyclr can send data directly to that interface.
API-Less Use Cases
API-less use cases don’t have to be limited to data import and export, of course.
Using similar mechanisms, a Cyclr template can enable your users to trigger behaviour and operations based on activity in the other apps. This means no publicly documented API is required.
We often propose these approaches to early-stage businesses. This is because there’s too much change in their core product to commit to a stable API. As well as established SaaS businesses that have an imminent new release to their API, but can’t afford to delay offering a specific connectivity option to their users.