Every day, the team at Pandium and I talk with B2B SaaS companies seeking a more efficient way to build integrations. Many initially consider building in-house, but integrations that involve data exchange between APIs present complex challenges in design, implementation, and ongoing management. Engineers often struggle with issues like outdated documentation, security requirements, manual tasks, and the need for specialized skills.
Low code and no code embedded integration platforms as a service (iPaaS) emerged as early solutions to this problem. They promised to simplify the integration process with drag and drop workflow builders and quick setup times.
However, beneath their convenience lie limitations that can hinder innovation and operational flexibility.
This article highlights the hidden pitfalls of traditional low code and no code embedded iPaaS solutions and presents an alternative that prioritizes a code-first approach to the embedded iPaaS space.
Before I dive into the limitations of traditional low code and no code embedded iPaaS solutions, it's important to understand the role of API connectors in facilitating integrations for these systems. This understanding sets the stage for exploring how these connectors shape the capabilities, limitations, and flexibility of embedded iPaaS platforms.
APIs (Application Programming Interfaces) enable communication between different software systems, allowing one system to request data and digital assets from another. Embedded iPaaS solutions often provide connectors, or API connectors, to facilitate communication between APIs, simplifying the integration process and reducing the workload for developers.
Pre-built connectors offered by low code or no code embedded iPaaS tools typically handle authentication and provide predefined actions and endpoints. These actions are presented visually within a workflow builder tool, allowing users to create integrations.
These predefined actions mostly facilitate what are called CRUD operations (create, read, update, delete), which, at a high level, define how data will be interacted with, organized, and maintained for an integration.
Now let's dive into the limitations of traditional low code and no code embedded iPaaS solutions:
Traditional embedded iPaaS solutions simplify API interactions by standardizing data and presenting it in visual blocks. However, this approach limits SaaS companies to a predefined set of functionalities, hindering their ability to customize integrations to meet unique needs.
For example, CRUD or webhook functionality might not be consistent across all API connectors an embedded iPaaS offers. If an API gets updated (this could be your API or your partner's API), or you want to work with a beta API there is often a significant time delay as you need to wait until the embedded iPaaS vendor releases an updated connector version based on the general availability API.
In addition, low code / no code platforms often need to prioritize which API connectors they build and maintain. If the API you need to connect to isn’t consistently requested by other customers, then support may not be available and maintenance and updates might be discontinued.
As applications and use cases grow, traditional embedded iPaaS solutions often struggle to keep up with evolving integration needs, creating bottlenecks for B2B SaaS companies. Changes to integrations have to follow the platform’s predefined actions and connectors, which limits flexibility and agility. This lack of adaptability can hold back innovation and prevent companies from fully harnessing the full power of APIs.
Low code and no code tools were created so "citizen" developers could tackle tasks that once required coding expertise. In integration, they promise users can build workflows with a visual builder.
However, just as in other areas (like web development), these tools often don’t deliver the productivity gains hoped for. Non-developers may be able to handle basic tasks, but someone with coding experience is often still needed to complete or troubleshoot integrations.
Using these platforms still requires significant time and training, especially for complex integrations. Even simple workflows can require intricate branching, with hundreds of decision trees.
Take a look at the example below—this integration, built in a visual workflow tool, shows how quickly things can get complicated.
This reliance on embedded iPaaS-specific knowledge ultimately reduces integration developers' productivity and slows down maintenance and updates.
Key practices like code reviews, automated testing, and version control can become challenging or simply unavailable in some low code/no code environments, which compromises both productivity and quality. Developers generally prefer working with code and familiar tools, where they can maintain high standards and operate efficiently.
But, don’t just take our word for it. One of our current customers, Justuno, switched from a popular no code integration solution for many of the same reasons—seeking more flexibility, control, and efficiency.
For years, Justuno relied on in-house developers to build and maintain their integrations with technology partners. However, as their platform expanded and APIs evolved, this approach became increasingly unsustainable due to enormous developer debt.
Seeking a solution, Justuno turned to a well-known traditional embedded iPaaS (Integration Platform as a Service) tool. They planned to outsource integration development entirely. Initially, things seemed promising. But after six months, 3rd-party development came to a standstill, leaving Justuno at the mercy of a stagnant platform and unable to make crucial updates or add new integrations.
Many low code / no code iPaaS tools are great for creating simple integrations with low data volumes and throughput limits, but struggle when it comes time to scale. For simple integrations where you need to process something like an email update a low code / no code tool may work very well. However if you need to do more significant actions (eg. get 200M records, do the ETL and then batch and feed them into your own API) then these systems often don’t have the resiliancy to deal with that type of data volume. This is due to a number of factors including:
These scalability issues place restrictions on the business value an organization can derive from their integration strategy and limit the use cases that an embedded iPaaS solution can be leveraged for.
Integrations that use pre-built connectors of low code and no code embedded iPaaS tools are 100% reliant on the platform, risking vendor lock-in and rendering integrations useless without the iPaaS. This restricts a company's ability to switch vendors and could result in lost access to crucial integration logic and code.
If the iPaaS vendor shifts their focus, reduces the development support that was initially promised or lacks support for APIs you may need in the future, the lock-in to the iPaaS platform can create bottlenecks to integration development and maintenance.
Many embedded iPaaS tools use a pricing model that includes a standard SaaS license fee to use the platform, and then additional usage based pricing. While usage-based pricing is becoming more and more common, embedded iPaaS tools typically calculate pricing on usage metrics that are very difficult for their customers to understand, measure, and use to predict costs.
Pricing is often calculated based on data volume and/or activity that is being sent from external systems back to the embedded iPaaS to sync with your API. While you may be able to understand and count what you have in your own systems, what will be sent from your customers is something that is impossible to understand with any certainty.
If a customer decides that they need to click a button constantly which triggers an API call, a recipe, workflow or task, then you are charged for this. If a customer decides to import and sync hundreds of records, you are charged for this. While many iPaaS vendors provide estimates of average use, these are only estimates and customers often find that in real-life there are too many unpredictable ways that other systems might be used.
Enter Pandium, a code-first embedded iPaaS solution that offers B2B SaaS flexibility, customization, and direct API access. It also provides the infrastructure needed for seamless integration deployment and management.
Pandium acts as a facilitator rather than an intermediary in the integration process. It empowers developers to quickly build, iterate, and deploy integrations at scale, providing a middle ground between in-house development and low code or no code iPaaS solutions.
While Pandium also offers connectors, its connectors don’t include predefined workflows and actions, and it doesn’t use a visual builder. Pandium connectors facilitate authentication between APIs and offer developers access to API Clients that support them with seamless API interactions.
Pandium provides developers with resources and code scaffolding to automate and streamline the local development of integration business logic, simplifying and accelerating the process. Meanwhile, the Integration Hub takes care of the necessary infrastructure to efficiently launch and manage integrations at scale.
Pandium is optimized for large data volumes with syncs processing much faster than more traditional iPaaS tools. Processing large data volumes was incorporated into the platform design from the beginning and is treated as a first-class concept. Syncs can be batched to enable more failsafe processing, and customers can implement concurrency within syncs to optimize for speed (which leads to better resilience.)
Pandium facilitates integration development by connecting to developers' repositories of choice. Developers are supported by Pandium’s Integration Development Kit to quickly code the business logic for their chosen integration and the Pandium CLI to allow developers to build, deploy and manage integrations directly from the command line.
Once an integration is built or updated locally and pushed to the repository, Pandium’s system handles the rest.
Pandium provides unlimited integrations and daily executions, meaning your customers can sync with your system as much as they want without creating additional cost.
When selecting an embedded iPaaS solution, it's essential to align the choice with strategic goals and integration needs. While low-code or no-code iPaaS may be great for simpler use cases, Pandium becomes a compelling choice for companies looking for a combination of innovation, flexibility, and speed.
