Engineering
Third-party portal automation: API, RPA, or browser agent?
Use a supported API when it covers the required operation, scripted browser automation when the interface is stable, and a browser agent when interpreting variable screens genuinely adds value.
That is a preference order, not a guarantee. The hardest question is not whether software can click the button. It is whether you can trust the resulting operation after a timeout, a login challenge, or an unexpected page.
1. API
An official API can expose explicit inputs, machine-readable results, and predictable errors. Ask whether it covers the entire business operation. An API that reads account data but cannot submit the required document is not a complete replacement for the portal.
API cons:
- Undocumented endpoints found in browser traffic are not a supported public API
- Credentials expire, permissions change, and a request can succeed on the server after the response never reaches you
Best for: repeatable, high-volume operations covered by an authorized integration. Record the requested action and reconcile the destination state before you retry an uncertain write.
2. Scripted RPA
A browser script can follow a known sequence of screens when no suitable API exists and the portal permits the automation. Prefer explicit page checks and meaningful element identifiers over screen coordinates. Confirm the account and the page before proceeding.
Script cons:
- Saved sessions still expire. Multi-factor authentication and account restrictions still apply
- A login challenge is a handoff, not something the automation is entitled to evade
Best for: consistent forms, known fields, and an operator who will maintain the journey when the portal changes.
3. Browser agent
A browser agent can interpret page content and choose the next action. That flexibility helps with variable layouts. It also adds a new error: the agent can misunderstand the interface or infer permission that was never given. Page content is untrusted input.
Agent cons:
- A portal page or uploaded document should not be able to change the task or authorize a new action
Best for: controlled workflows where screen variation is real, results are inspectable, and ambiguous steps can be escalated. Keep consequential actions behind a separate check.
Compare the exception path first
Give each approach the same authorized test: an expired session, an unavailable page, a changed field, invalid input, and an uncertain submission. An operator needs the account, the intended action, the last confirmed state, and evidence of any completed submission.
Sometimes the right answer is an API for most steps and a supervised browser step for the remaining gap. Sometimes the portal's rules make automation unsuitable. Both are better than an unsupported dependency.
If you are evaluating portal automation, tell me the portal, the authorized operation, and the exception that currently sends the work back to a person.
Message me