A new business application is only useful if it fits into the systems you already run. Customer records live in the CRM, invoices in the finance system, staff in the HR platform, and some core process probably still runs on an older system nobody wants to touch. To integrate no-code apps with existing systems, you need to know which connection suits which job, and how to keep the new application from becoming another island.
Start by mapping the data flows
Before choosing any technology, draw the picture. For the process you are building, list:
- Where each piece of data starts. Which system is the source of truth for customers, products, staff, prices?
- Where it needs to go. Which systems need to know when something changes in the new application?
- How fresh it must be. Does a change need to arrive immediately, within the hour, or is a nightly refresh fine?
- Who owns each system, and who needs to approve a new connection to it.
That map usually shows that most integration needs fall into a few patterns. Each has a natural tool.
Import: bringing existing data in
The first integration is almost always a one-off or occasional import. You have years of records in a spreadsheet or an existing database, and the new application needs them from day one.
Vibe imports CSV and SQL, and can build a working application directly from a spreadsheet or existing database, generating the data model, screens and workflows in hours. Import is also useful on an ongoing basis for systems that can only produce exports: many older systems can write a file on a schedule even when they have no modern interface. Our guide to moving from spreadsheets to a business application covers cleaning and re-importing data in detail.
REST: reading from and writing to other systems
Most modern systems, and many older ones, offer a REST API. It lets the new application ask another system for data or send data to it at the moment it is needed.
Typical uses:
- Looking up reference data, such as checking a customer's account status in the CRM when a request is raised.
- Pushing a result onwards, such as creating a purchase order in the finance system once an approval is complete.
- Keeping a shared record in step, such as updating a contact's details in both places.
When you use REST, agree which system owns each field. If both systems can edit a customer's address, decide which one wins, or you will end up with two versions of the truth.
Webhooks, events and your own API
Polling another system every few minutes to see whether anything has changed is wasteful and slow. Webhooks and events reverse the direction: the other system tells the application when something happens.
For example, say a field service team uses a no-code application to schedule inspections. When the CRM records a new site, a webhook can create the matching record in the inspection application straight away. When an inspection is marked complete, an event can notify the billing system. Nobody re-keys data, and nobody waits for a nightly job.
Vibe applications can connect over REST, webhooks and events in both directions. The FAQ on connecting to your other systems summarises what is supported.
Integration also works best when it is two-way. A no-code application that can only call out, and cannot be called, stays a dead end for other teams. Vibe applications can expose their own APIs, so the data they hold is available to reporting tools, other applications and the developers who look after your core systems, under the same role-based access rules as the screens.
Our article on why no-code apps should have real APIs looks at this in more depth.
Identity: single sign-on as integration
Integration is not only about data. Your identity provider is a system too, and connecting to it is one of the most valuable integrations you can make. With single sign-on over SAML and OIDC, people sign in with the account they already have, and when they leave, disabling that account removes their access to the application. Role-based access on every entity and action then decides what each person can see and do, and audit logging records what they changed.
Working alongside legacy systems
It is tempting to see a new application as the first step to replacing an older system. Sometimes it is. More often, the better approach is to leave the legacy system doing what it does reliably and build the new application around it: capturing the process that the old system handles badly, and passing clean results back.
A few practical points help:
- Start read-only. Pull data from the legacy system first; write back only when the process is proven.
- Use the gentlest interface available. If the old system has an API, use it. If it only produces files, schedule an export and import it.
- Keep the owners involved. The team that maintains the legacy system needs to know what is connecting to it and why.
- Make changes reversible. Every change to a Vibe application is versioned and can be undone, and deployments use staged environments with one-step rollback, so integration changes can be tested before they reach live data.
The managed platform matters here too. bizapps.io runs the infrastructure underneath, including secret rotation for the credentials integrations depend on, and logs, metrics and traces that help you find out why a connection failed.
Plan your first connection
Pick one process where people currently re-key data between two systems. That is usually the clearest win. The platform page covers the integration and operations details. If you would like help, the services team can build the application and its integrations for you, or you can apply to the design partner programme and build it yourself with direct access to our engineers.