Lava vs Viktor: Connectors vs Interface Control
Every integration platform makes the same promise: connect your tools, automate your work. Viktor makes it with 3,200+ prebuilt connectors, which is a genuinely large catalog and covers most of what a modern SaaS company touches.
The catalog is also the ceiling. When the tool you need is not in it, the answer is to build a custom connector, which means finding API documentation, getting credentials, and mapping endpoints before any work happens. For a vendor portal or an internal admin panel, that documentation frequently does not exist.
Lava takes a different route to the same goal: it operates the interface a person would use, and calls APIs directly when one is available. This post is about when each approach is the right one.
Key Takeaways
- Viktor's 3,200+ connectors are the strongest argument for it. If your stack is mainstream SaaS, prebuilt connectors are more reliable and faster to set up than anything driven through a UI.
- Connectors are a catalog, not a universe. Anything outside it needs a custom connector, and a custom connector needs documentation the tool may never have published.
- Lava works through the interface as well as the API, so a tool with no public API is not a special case that needs an exception process.
- Interface control has real costs: it is slower per action than an API call, and it breaks when a vendor redesigns a page. Connectors do not have that failure mode.
- Most companies need both. The honest question is which half of your stack is the painful half.
The Connector Model, and What It Is Good At
A connector is a maintained integration: someone wrote the auth flow, mapped the endpoints, and keeps it working when the vendor changes the API. When one exists for your tool, it is the best option available. It is fast, it is structured, it fails loudly instead of silently, and you did not have to build it.
Viktor has built a lot of these. For a company running Salesforce, HubSpot, Slack, Google Workspace, and a normal set of SaaS products, the catalog will cover nearly everything, and the setup is genuinely a few clicks.
Where connectors win outright
High-volume, repetitive, structured work: syncing thousands of records, running scheduled data pulls, anything where an API's speed and reliability matter more than flexibility. Interface control is the wrong tool for that job.
Where the Catalog Runs Out
The gap shows up at the edges of the stack, and the edges are bigger than they look.
Legacy systems. The billing platform installed in 2011 that finance still runs payroll through. It has a web interface. It does not have a public API, and nobody at the vendor is going to write one.
Vendor portals. Every supplier, insurer, and logistics provider has its own portal. Each one is a login and a set of screens. Almost none publish API documentation to customers.
Internal admin panels. The tool your own team built. There may be an API, but nobody wrote it down, and the person who would know left last year.
For all three, the connector model has a documented answer: build a custom connector. That answer assumes documentation exists. When it does not, the work does not get automated, and it stays manual indefinitely.
The exception becomes the workload
Connector platforms treat undocumented tools as edge cases. In practice those tools tend to be where the manual work has piled up, precisely because nothing else could automate them.
What Interface Control Changes
Lava's agent reads the screen and acts on it the way a person does: clicking, typing, navigating. It also calls provider APIs directly when one is available, so structured work still goes through the structured path.
The practical difference is that there is no qualifying step. You do not check whether a tool is supported before you start. If you can sign in and do the task yourself, the agent can work there too. A vendor portal with no API and a Gmail inbox with a mature one are the same kind of target.
That is the whole claim, and it is worth being precise about its limits, which is what the next section is for.
An Honest Comparison
| Capability | Viktor | Lava |
|---|---|---|
| Prebuilt integrations | ✓ 3,200+ connectors, maintained | ✓ 400+ providers, smaller catalog |
| Tools with no public API | ✗ Custom connector required | ✓ Works through the interface |
| Undocumented internal tools | ✗ Blocked without documentation | ✓ Same as any other screen |
| High-volume record syncs | ✓ Built for it | ✓ Via API, but slower through a UI |
| Resilience to vendor UI redesigns | ✓ Unaffected | ✗ Interface flows can break |
| Breadth of maintained connectors | ✓ Considerably larger | ✗ Smaller catalog today |
| Model choice | ✓ OpenAI, Anthropic, Google | ✓ Multiple models, one wallet |
| Slack support | ✓ | ✓ |
Two rows in that table are Lava losing, and they are not throwaways. Interface flows are more fragile than API calls: when a vendor moves a button, an agent driving the screen has to adapt, while a connector keeps working. And Viktor's catalog is meaningfully larger than ours. If your stack sits entirely inside it, that breadth is worth more than anything interface control adds.
How to Choose
Choose Viktor if your tools are mainstream SaaS with good APIs, your work is high-volume and structured, and you want maintained integrations you never have to think about. That is a real and common situation, and connectors are the better fit for it.
Choose Lava if a meaningful share of your work happens in tools the catalog does not reach: vendor portals, legacy internal systems, admin panels nobody documented. The value is not that interface control is technically superior. It is that the work currently done by hand stops being done by hand.
The realistic answer for many teams is both, at least for a while. Connectors handle the structured core, interface control handles the long tail. What matters is not letting the long tail stay manual just because it never made it into a catalog.
The Bottom Line
Connectors and interface control solve the same problem from opposite directions. Connectors are excellent where they exist and unavailable where they do not. Interface control is universally available and less efficient per action.
Viktor bet on catalog depth, and 3,200+ connectors is a serious bet that pays off for mainstream stacks. Lava bet that the tools without APIs are where the unautomated work actually lives. Which bet fits you depends on where your manual work is piling up, and that is worth checking before comparing feature lists.
How Lava Helps
Lava's agent reaches your tools two ways: Lava Gateway routes API calls to connected providers through a single auth layer, with every request metered and logged, and interface control handles the tools where no API is on offer. The agent picks whichever path the task needs, so you are not choosing per tool.
Lava Monetize handles the money side. One prepaid balance covers every model call and every provider request, with spending limits enforced automatically, instead of separate billing for each service the agent touches.
If your team is maintaining a list of tools "we can't automate yet," that list is the thing worth testing. Try Lava against the worst item on it.
