Most system integration work assumes every platform in scope will talk if you ask it correctly: send a request, get structured data back, move on. That assumption breaks the day one of the platforms turns out to be a supplier portal with a login screen and nothing else behind it — no API, no export schedule, no technical contact who can promise one. This is common enough in recruitment, care and professional services that it deserves its own answer, not a workaround bolted onto a project plan written for APIs.
What system integration means when there is no API
System integration is usually described as systems exchanging data automatically. That definition quietly assumes both ends can be asked something and will answer in a structured way. A portal-only platform breaks the assumption at one end: it was built for a person to read and click, not for another system to query. The work is still integration in the sense that matters to an operations director. One record gets entered once, and there is one place to check its status. Only the method has to change, because the platform will not.
The portal-only platform problem
These platforms turn up constantly once you go looking: a compliance-checking service, an umbrella company's own site, an industry body's membership system, a council or government portal. They exist because the organisation running them wanted control over how their data is entered and viewed, and an API was never part of the brief. There is often no support contact who can even answer whether one exists, because the answer sits with a product team that built the portal for its own customers, not for other people's systems.
The consequence lands on whoever owns the process either side of it. If one leg of a workflow is a portal, everything downstream inherits a manual step, and that manual step is where visibility disappears — nobody can query the status of a record that only exists on someone else's screen.
Three honest options
Ordered from least to most work, and worth working through in that order rather than jumping to the third.
Ask the supplier for an export
Before building anything, ask a direct question: does the portal produce a scheduled export, a reporting feed, or a data-sharing file, even one a person has to download by hand. Plenty of portals that show only a screen still generate a CSV or a report behind a menu nobody checks. If a file exists on any cadence, take it — it is the option with the fewest moving parts and nothing to maintain against a screen that can change without notice. This is a supplier relationship question first, not a technical one, and it is worth asking before assuming the answer is no.
Operate the screen, under its own credentials, with every action logged
Where no export exists and the platform still has to be reached, the remaining route is something that acts the way a person would: log in, read what is on the screen, enter what needs entering, log out. We build this as a defined job for an AI digital worker rather than a script running quietly in the background. The AI worker holds its own login to the portal, kept separate from any person's account, and every action it takes writes to an audit trail an operations director can open: what page it was on, what it read, what it entered, what it did next.
No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client.
This route carries a cost the first one doesn't. The portal was built for a person, and if its screen changes without notice, the worker's job has to change with it. That is an ongoing maintenance cost, not a one-off build cost, and it should be scoped and reviewed as one rather than left to surface as a surprise months later.
Access and credentials
Because this route means something other than a named employee is signed into a supplier's system, access has to be set up deliberately rather than inherited from an existing staff login. A dedicated account, scoped to only the screens the job needs, is the starting point. Whether the supplier's terms permit an account being used this way is a question worth putting to them directly rather than assuming; some portals are licensed per named human user, and that licensing detail decides whether this route is even available before any build work starts. The audit trail exists precisely so that, if the supplier ever asks what happened on their platform and when, the operations director has a complete answer rather than a guess.
Replace the platform
Sometimes the honest answer is neither of the above: build a system that does what the portal does and stop depending on someone else's screen at all. This fits when the portal-only platform sits at the centre of the process rather than at its edge, when the supplier has no interest in ever offering a feed, or when the ongoing cost of watching and maintaining screen operation outweighs the cost of not needing it. That is bespoke back-office systems work rather than an integration around someone else's platform, and it deserves to be named as its own decision rather than defaulted into.
Reconciliation before cut-over
Whichever route is chosen, run the new path and the old path side by side before anything goes live. Take a real set of records, run them through the new process, and compare the result entry by entry against what the manual process would have produced. Every mismatch needs an explanation, not a shrug: it usually means one of the two paths misread a field, not that the systems were always slightly out of step. Cut over once mismatches are down to genuinely understood edge cases, not because a deadline arrived first.
Monitoring after go-live
Integration work that skips monitoring degrades quietly the moment either platform changes something. The portal-only leg is the one to watch hardest, because it has no version number, no changelog and no contract obliging the supplier to warn anyone before they redesign a screen or add a mandatory field. Build the check for "did this run, and did the result match what was expected" as its own step, separate from the process itself, so a fault becomes an escalation to a named person rather than a silent gap in the records nobody notices until a client asks.
When not to integrate
Not every portal-only platform is worth connecting to. If the workflow it sits in runs rarely, if the volume through it is genuinely small, or if the organisation is already planning to leave that supplier, the honest recommendation is to leave the manual step exactly where it is and spend the effort somewhere it earns more back. Ask what the manual step actually costs before building anything around it. Sometimes the answer is "not much", and the right project is a different one entirely.
Where this comes up
This is one of the integration questions we hear most from recruitment and staffing agencies: compliance and referencing platforms are the classic portal-only case, sitting between a candidate's paperwork and a placement going live. The same three options apply to any organisation with a supplier platform that will not talk to anything else.
If a platform in your stack has no API and you want an honest read on which of these three fits, talk to us. Bring the platform and the workflow it sits inside, not a wishlist.
No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client.
A few useful questions.
How do you integrate a system that has no API?
Is having a worker operate a supplier portal the same as screen scraping?
What happens if the supplier changes their portal after go-live?
