Case study 04

Automating a process with no API

At an AI document automation platform for institutional financial services.

Problem

Source documents lived in third party portals with no API. The industry norm was vetted humans holding standing portal credentials and checking manually. The real barrier wasn't speed. The manual standard was already next business day. It was trust. Clients hesitated to extend standing credentialed access to anyone.

What I built

Browser automation that logs in, navigates, and retrieves newly posted documents continuously, including handling emailed two factor codes. A visual model failure detection step catches when the automation breaks, and a client approved third party is notified to retrieve manually. Download logs are reconciled against ingestion, so there's no silent gap between what the portal published and what was processed.

Document uploaded to portalforwarded automaticallyPortal notification emailClient processing queueextracts metadata + 2FA codePortal 2FA emailreceivedforwardedAutomated retrieval startsloginFailure detectionvisual modelDocument uploaded to portalProcessed document queuereconciled against ingestionon failureApproved thirdparty notifiedmanually

Redrawn from the original with generic labels. Structure unchanged.

The decision that mattered

Browser automation against an unversioned UI is inherently fragile. That fragility wasn't solved. It was bounded. Failures are detected and routed to a contracted human backstop rather than silently producing nothing. Designing the failure path was the product decision, not an afterthought. In practice the automation held and the fallback was rarely exercised, but the guarantee is what made the service sellable.

Commercially, it changed the nature of portal access from trusting a credentialed human to running a controlled, auditable, automated process. That removed an adoption barrier for security conscious institutional clients. It's described here as 24/7 automated retrieval with a contracted human fallback, without a specific response time figure, since the automation held in practice and that number was never truly exercised.

What I'd revisit

Failure detection was tuned against the portal layouts I'd actually seen fail. A slower, more deliberate visual regression baseline across every supported portal, refreshed on a schedule rather than reactively, would catch a slow layout drift before it produces a false negative instead of after.