API Integrations for MSPs: How to Build Them Without a Dev Team
Clients now ask their MSP to connect the software that runs their business, often software with no API. Here is how to deliver that work without hiring developers, and without letting fragile automations eat your margin.
Most MSPs build custom integrations without a dev team in one of three ways: low-code workflow tools for systems that have an API or connector, robotic process automation (RPA) for screens that have nothing else, and a development partner for the integrations that have to be reliable. The right mix depends less on the tool and more on who will fix it when it breaks, and who pays for that time.
This guide is for managed service providers and IT consultants whose clients have started asking for API integrations and automation that touch their core business software. It covers the options, where the hidden costs sit, and how to sell the work so it adds to your margin instead of draining it.
Why integration requests are squeezing MSP margins
For years the MSP model was predictable: devices, networks, Microsoft 365, phones and a helpdesk, all priced per user or per device. Automation requests do not fit that model. A client asks you to "connect the booking system to the accounts package" or "have the AI voice agent create the job in our practice software", and the work is part project, part ongoing support.
The difficulty usually sits with the client's core system. In many industries there is one package everybody uses, and it may offer no public API at all. If you are not sure whether a system really has no way in, start with our guide to integrating software that has no API, which covers the checks to make first.
When there is no API, the quick fixes are screen automation or a chain of Zapier-style steps. Both can work. Both can also become the support ticket that never closes, which is where margin disappears.
What are your options without developers?
1. Low-code workflow tools
Tools such as Power Automate cloud flows, n8n and Zapier connect systems that already have an API or a ready-made connector. They are quick to build, easy to hand over and good for moving data between mainstream cloud apps: forms to CRM, CRM to accounts, alerts to Teams.
Two things to check before you standardise on one:
- How usage is billed. Zapier counts a task as any successful action a Zap runs; triggers and filters do not count. A ten-step workflow that runs a few hundred times a day becomes thousands of tasks a month, so model the volume before you quote a fixed fee.
- How the licence treats you as a service provider. n8n's self-hosted edition is under the Sustainable Use License, which allows use "for your own internal business purposes" and limits providing it to others. A common approach is to install it in each client's own environment, or to check n8n's commercial options, rather than running every client's automations on one shared server.
2. RPA for systems with no API
Robotic process automation drives an application the way a person would, clicking buttons and typing into fields. Microsoft describes desktop flows as the option for applications that lack a connector and have no API to build one with. That makes RPA the honest answer for some legacy and desktop systems.
The costs are easy to underestimate:
- Licensing per bot. In Power Automate, an unattended desktop flow needs a Process licence allocated to the machine, and each Process licence runs one desktop flow at a time. Running several in parallel means buying a licence per parallel run.
- Breakage when screens change. RPA finds buttons and fields through selectors. Microsoft offers fallback selectors and text-based selectors, which it describes as more resilient to future changes in an application's structure. Every vendor update to the client's software is a potential call-out.
- A machine to look after. An unattended bot signs in to a Windows machine (or a Microsoft-hosted one) to run, which becomes another asset to patch and monitor.
3. A small custom integration layer
Between low-code and a full software project there is a middle option: a small, purpose-built service that sits between systems. It might read an export the core system already produces, watch a shared folder or database the vendor permits access to, or wrap a stable screen automation behind a clean interface so everything else talks to that instead.
It needs real development skills to build, but once built it is usually the most stable option, because it can validate data, retry failures, log every run and alert someone before the client notices.
4. A development partner
The fourth option is not a tool. You keep the client relationship, the discovery and the support, and a development studio builds and maintains the integration layer behind you, either white-labelled under your brand or introduced as your partner. You sell the outcome; they carry the engineering risk.
How the options compare
| Approach | Best for | Main ongoing cost | Fragility |
|---|---|---|---|
| Low-code workflows | Cloud apps with APIs or connectors | Task or run volume, plus licences | Low to medium |
| RPA desktop flows | Legacy screens with no API | Bot licences, machines, fixes after updates | High |
| Custom integration layer | Core systems with exports, databases or stable files | Hosting and occasional maintenance | Low once built |
| Development partner | Anything you cannot support in-house | Partner fees, priced into your offer | Depends on the partner's monitoring |
How to choose for each client request
Work through the same questions every time:
- Is there an official route in? API, webhook, scheduled export, import format or a marketplace connector. Ask the vendor directly; many have partner APIs that are not advertised.
- How often does the data move, and what happens if it is late or wrong? A daily report can tolerate a failed run. An appointment that never reaches the diary cannot.
- How often does the core system change? Frequent releases rule out heavy screen automation.
- Who will be paged when it fails? If the answer is "us, unpaid", the build price is the wrong number to focus on.
- What does the client's contract with the vendor allow? Some vendors prohibit automated access to their interface. Check before you build, not after a suspension.
As a rule of thumb, use low-code where an API exists, keep RPA for small, stable, low-volume steps, and move anything business-critical onto a monitored integration layer.
How to sell integration work without losing margin
The MSPs that make money from automation tend to package it the way they package everything else:
- Paid discovery. A short, fixed-fee assessment that maps the systems, confirms the access routes and produces a written scope. It filters out requests that are not worth automating.
- Fixed-price build. A defined integration with agreed inputs, outputs and acceptance tests.
- A monthly managed integration fee. Monitoring, alerting, fixes after vendor updates and a set number of change requests. This is what turns a one-off project into recurring revenue and pays for the breakages that would otherwise come out of your margin.
Whatever you charge, write down what counts as a change request. Most margin is lost to "small tweaks" that were never in scope.
What to agree before you build
- Ownership. Who owns the workflows, code and credentials if the client leaves, or if you change partner.
- Data protection. An integration that moves personal data makes you, and any partner, a processor. In the UK the ICO sets out what a controller-processor contract must include, including authorisation for sub-processors. EU GDPR has equivalent rules, and US clients may have sector rules such as HIPAA for health data.
- Credentials and access. Use service accounts rather than a staff member's login, store secrets in a vault and record who can change what.
- Monitoring. Every integration should log its runs and alert a named person on failure, before the client's staff discover missing data.
Frequently asked questions
01.Can an MSP offer custom integrations without hiring developers?
Yes. Low-code tools cover many API-based integrations, and a development partner can build and maintain the harder ones behind your brand. The key is pricing in ongoing support rather than selling a one-off build.
02.Is RPA a good long-term solution for software with no API?
It can be for small, stable, low-volume tasks. For business-critical processes it tends to be expensive to keep running, because every change to the application's screens can break it and each parallel bot needs its own licence.
03.Should we white-label integration work or introduce a partner?
White-labelling keeps the client relationship entirely with you; introducing a partner can make support boundaries clearer. Either works if the contract sets out ownership, data processing terms and who responds when something fails.
If your clients are asking for automation that touches software with no API, we build and maintain integration layers and AI agents and automation for small and mid-size businesses, and we work alongside IT providers who want to offer this without building a development team. For larger builds, see our custom software development service, or get in touch to talk through a client request.
