How do you integrate with software that has no API?

Most integration guides assume a best case: the system you need to connect to has a documented REST API, you have admin access, and you can generate credentials. Half a day's work and you're pulling data.

Real business integration frequently looks nothing like that.

The system holding your data might be owned by someone else entirely — a client, a franchisor, a principal contractor. You might have a user account but no admin rights. There may be no API at all, or an API you're not permitted to use. Multi-factor authentication may sit in front of everything, with sessions that expire aggressively.

You still need the data. Here's how we think about that problem.

Have you exhausted the legitimate routes?

Before doing anything clever, work through the boring options properly. A surprising number of "no API" situations turn out to have one.

• Ask. Genuinely. Contact the vendor and ask whether API access is available, what it costs, and what the process is. Sometimes it exists but isn't advertised on the pricing page. Sometimes it's available on a higher tier, and the upgrade costs less than the workaround.
• Check for scheduled exports. Many systems can email a report on a schedule or drop files to SFTP. If you can get a nightly CSV, you don't need real-time integration — you need a file watcher and a parser, which is far simpler and far more robust.
• Look for existing connectors. Zapier, Make, Power Automate and the various integration platforms have connectors for a lot of systems. If one exists, the vendor has already solved the authentication problem for you.
• Check whether the data lives somewhere else too. Sometimes the system you can't access writes to a database, a data warehouse or a reporting tool that you can access. The integration point doesn't have to be the application itself.
• Ask the data owner. If the system belongs to a client or partner, they may be able to grant access, run exports for you, or authorise API credentials on their account. This is often the fastest route, and it's frequently overlooked because people assume the answer is no.

Only when all of these fail does browser automation become the reasonable answer.

Where is the legal and ethical line?

This matters more than the technical question, and it's where we'd urge genuine caution.

• Read the terms of service of the system you're automating against. Many explicitly prohibit automated access, scraping or programmatic interaction outside their published API. Violating those terms can breach contract, and in the UK it can also raise questions under computer misuse legislation.
• Understand who bears the risk. If you commission this kind of automation from a consultancy and it breaches a third party's terms, who is liable? In most contracts, the client warrants they have the rights and permissions necessary — but that clause only helps if it's actually there. Put it in writing, and be clear about who is confirming that access is permitted.
• We won't build automation that breaches third-party terms. That's a line we hold, and we'd encourage others to hold it. Not primarily out of legal caution, though that matters — but because a system built on a breach is a system that can be switched off without warning, leaving you stranded.
• Distinguish between the vendor's system and your own data accessed through it. These are different situations with different risk profiles. A user reading their own records through a screen they're licensed to use is a materially different proposition from scraping a public site at scale. The former is often defensible; the latter often isn't.

If you're unsure, get proper legal advice. This article isn't it.

How does attended browser automation work?

Assuming you've cleared the above, the approach that works for locked systems with multi-factor authentication is attended browser automation.

The core idea: rather than trying to bypass authentication, you work within an authenticated session that a human has legitimately established.

The flow looks like this.

• Step 1. A desktop agent launches a real browser.
• Step 2. The user logs in normally — username, password, the multi-factor challenge, the lot.
• Step 3. Once authenticated, the agent operates within that live session.
• Step 4. The agent reads pages, extracts data and sends it to your system.
• Step 5. When the session expires, the agent detects it, stops cleanly and prompts the user to log in again.

What this deliberately does not do: store passwords, bypass multi-factor authentication, share sessions between users, or run unattended overnight.

That last constraint is a genuine limitation, and it's the honest trade-off. You cannot run this at 3am. It runs when a user is logged in, which usually means during business hours.

How do you make it reliable?

• Use a real browser, not a hidden one. Automation tools such as Playwright and Puppeteer can run a full, visible browser. A visible browser means the user can see exactly what's happening, which matters for trust and for debugging.
• Use the user's installed browser where possible. Playwright can drive the user's actual Chrome or Edge installation rather than a bundled copy. The automation then runs in the browser the user already knows and trusts, and there are fewer binaries to ship and code-sign.
• Detect session expiry properly. Don't just check whether a request failed. Look for the specific signals — a redirect to the login page, a particular error response, the absence of an expected element. Handle it gracefully: stop, notify the user, and don't retry blindly.
• Read, don't write, until you've earned it. Start with read-only extraction. Write-back — updating records in the source system — is a much higher-risk operation. When you do add it, gate it behind human approval: propose the change, show exactly what will change, require a click.
• Respect rate limits. Even if none are documented, don't hammer the system. Add delays between requests. Behave like a fast human, not like a bot. This is both good manners and good self-preservation.
• Expect the screens to change. Any interface you're automating against will be redesigned eventually, and nobody will tell you. Build the automation to be as resilient as you can, monitor for failures, and budget for maintenance.

What does deploying a desktop agent involve?

Shipping a desktop agent to client machines brings its own problems that pure web work doesn't.

• Code signing. Windows Smart App Control can block unsigned executables outright, and SmartScreen greets them with alarming warnings, so you need a code-signing certificate. Standard certificates build SmartScreen reputation gradually; extended-validation certificates typically get there faster, though Microsoft no longer guarantees instant trust — and they cost roughly £320 to £700 a year. Azure Trusted Signing (recently renamed Azure Artifact Signing) is a much cheaper alternative at roughly 10 US dollars a month, open to verified UK businesses, though it issues standard rather than EV certificates.
• Antivirus false positives. A program that automates a browser and sends data over the network looks, to a heuristic scanner, quite a lot like malware. Expect false positives. Signing helps enormously; submitting the software to antivirus vendors for whitelisting helps too.
• Updates. You'll need to ship fixes when the target system's screens change. Build automatic updates in from the start; chasing users to manually reinstall is miserable.
• Support. Something will go wrong on a machine you can't see. Build good logging and a straightforward way for the user to send you the logs.

Could you just parse the output instead?

Worth considering before you build any of the above.

If the system you're integrating with produces documents — PDFs, exported reports, emails — you might not need to automate the screens at all. Parse the output instead.

This is dramatically simpler, has no terms-of-service exposure, and doesn't break when the interface is redesigned. The trade-off is that you only get what's in the document, and you depend on a human generating it.

For a lot of use cases, that's a perfectly good trade. If the alternative is a fragile automation with legal exposure, "have someone export a PDF and we'll parse it" starts looking rather attractive.

When should you walk away?

Some integration requests should be declined.

• When the terms of service clearly prohibit it and permission can't or won't be obtained.
• When the value of the integration doesn't justify the ongoing maintenance burden.
• When unattended operation is wanted on a system with multi-factor authentication — that would mean storing credentials or bypassing the security, and we won't do either.
• When there's a supported route being avoided purely on cost, and the workaround is more expensive over time.

Saying no to these is easier when the reasoning is explained up front. Most people understand "that would breach their terms and put you at risk" once it's spelled out.

The short version

Integration with locked systems is possible, but the order of operations matters.

• Exhaust the legitimate routes first. Ask the vendor, check for scheduled exports, look for existing connectors, and ask the data owner.
• Confirm permission in writing. Make sure the risk is properly allocated before anything is built.
• Consider parsing output documents before automating any screens.
• Work within authenticated sessions, never around them.
• Read before you write, and gate any write-back behind human approval.
• Budget for maintenance, because the interface will change.

The technical problem is usually solvable. The question worth asking first is whether it should be.

Frequently asked questions

Can you integrate with a system that uses multi-factor authentication?

Yes — but not unattended. Attended browser automation works within a session the user has legitimately logged into, multi-factor challenge and all. When the session expires, the agent stops cleanly and asks the user to log in again. Anything that stores credentials or bypasses the security check is off the table.

Is browser automation against the rules?

It depends entirely on the system's terms of service. Many prohibit automated access outside their published API, and breaching those terms can have contractual consequences and, in the UK, potentially legal ones. Reading your own records through a screen you're licensed to use is a very different proposition from scraping a public website at scale. Check the terms, get permission confirmed in writing, and take proper legal advice if you're unsure.

What's the simplest alternative to automating a screen?

Parsing the documents the system already produces — PDFs, exported reports, emails. It's far simpler, carries no terms-of-service exposure and doesn't break when the interface changes. The trade-off is that you only get what's in the document, and someone has to generate it.

Why can't this kind of automation run overnight?

Because it deliberately works inside a session a real person has opened, and it stops when that session expires. Running at 3am would mean storing passwords or bypassing multi-factor authentication — which defeats the security the system's owner put there, and is exactly the kind of shortcut that gets access revoked without warning.

Stuck with a system that won't talk to anything else? Book a free 30-minute discovery call and we'll tell you honestly whether it can be connected — and whether it should be.