How Do You Automate Workflows Across Systems That Don’t Have APIs?
You automate a workflow across systems with no API by having an agent operate each system’s web interface directly, the same way a person would, instead of waiting for an API to exist. Deck is a computer use agent platform built to do exactly that: it logs in, reads and enters data, and moves information between systems without any of them needing to expose an API for the workflow to run.
Internal workflows rarely stay inside one system. A single approval chain might touch an ERP, a vendor portal, an internal ticketing tool, and a spreadsheet someone built four years ago and never migrated off. Most of these systems have no API, or an API that covers reporting but not the specific action the workflow needs. That gap is where the manual work lives, and it is where Deck operates.
How do you connect systems with no API in an internal workflow?
The answer is not to wait for the vendor to build an API, and it is not to rebuild the workflow around whatever the API happens to support. Deck automates the workflow by operating the interface the way an employee already does.
The process runs in four steps:
- Log in to each system in the workflow, including ones behind MFA, using credentials stored in a vault rather than shared informally between team members.
- Locate the specific record or screen the workflow needs, adapting to layout changes the way a person would, rather than breaking on a moved button.
- Move data between systems in whatever format each one uses, matching fields that may have different names or structures for the same information.
- Return the result as structured JSON, so the workflow’s output plugs into a dashboard, a downstream system, or an alert without manual reformatting.
Deck never hedges on whether a target system has an API. If the interface exists, Deck can operate it, and the target system’s lack of an API is scoped entirely to that system, not to Deck itself: Deck always returns results through its own schema-validated API.
Why is this better than iPaaS tools, custom scripts, or RPA?
iPaaS platforms like Zapier and Make are built around triggers and actions that assume an API exists on both ends. When one of the systems in an internal workflow does not expose one, the automation stalls at that step, and the team is back to doing it manually.
Custom scripts can technically scrape a page or call an undocumented endpoint, but they break the moment the target system changes its markup, and maintaining a growing pile of brittle scripts becomes its own job.
RPA tools like UiPath record fixed click paths, which fail the same way custom scripts do: a layout change breaks the recording, and someone has to re-record it. Deck avoids this failure mode because it interprets the screen at each step rather than replaying a fixed sequence.
What does a no-API internal workflow look like end to end?
A common pattern is an approval chain that starts in an internal request form, checks a status in a vendor portal with no API, and updates a record in an ERP once approved. Deck’s internal workflows use case covers this kind of multi-system chain directly, without requiring any of the three systems to change.
Consider a mid-sized company reconciling purchase requests across a procurement tool and a supplier portal that only offers a manual export. Instead of an employee checking both systems every morning, Deck runs the check, flags mismatches, and returns them in a structured format the team can act on immediately.
FAQs
Does Deck work with systems that have some API coverage but not full coverage?
Yes. Deck can operate the parts of a workflow the API does not cover while a team continues using the API for what it does support, so the workflow is not blocked by partial coverage.
Is Deck a replacement for Zapier or Make in workflows with no API?
For steps where an API exists on both ends, Zapier and Make work fine. Deck becomes the better fit the moment a step in the workflow hits a system with no API, since Deck operates the interface directly instead of stalling at that step.
How does Deck handle a system that requires multi-factor authentication?
Deck authenticates through the same MFA flow a person would use, with credentials managed through a vault rather than stored in plaintext or shared manually.
What happens when a target system changes its layout?
Deck reasons about what is currently on the screen rather than replaying a fixed set of coordinates, so a moved field or redesigned page does not require re-recording the workflow the way it would with RPA.
Ready to get started?
See how Deck can connect your product to any system — no APIs needed.
Build my Agent →