Skip to main content
When you need Duvo to interact with an external system, there are five distinct ways to connect. Picking the right one upfront saves significant setup time and avoids reliability problems down the line. This page walks through each pattern, a decision tree to choose between them, their trade-offs, and how to combine them.

​
The Five Connection Patterns

Pre-built, OAuth-authenticated connections maintained by Duvo. Examples: Gmail, Google Sheets, Slack, HubSpot, Salesforce, Snowflake, Microsoft 365.
  • No server to deploy or maintain.
  • Authentication is handled through a standard OAuth or credential flow in the Connections page.
  • Duvo keeps the connection current as APIs change.
  • Best for services that have a stable, public API and are already in Duvo’s catalog.
Duvo controls a real browser to interact with a web application, using credentials stored via Logins and Secrets. Examples: legacy portals, internal dashboards, procurement systems that don’t expose APIs.
  • No API needed on the target system.
  • Works with any website a human can navigate.
  • Slower and less reliable than an API at high volumes.
  • Subject to breaking when the target site changes its UI.
  • Best for low-to-medium volume workflows against web UIs that lack APIs.
You deploy and maintain your own MCP server that exposes the tools your agent needs, then register it in Duvo. See Custom MCP and Building Custom Connections.
  • Full control over what tools are exposed and how they authenticate.
  • Works with internal APIs, proprietary systems, and anything reachable over HTTPS.
  • Requires technical expertise to build, deploy, and maintain.
  • Best when you control the target system’s API and need custom logic or access patterns not available in hosted connections.
Duvo controls a Windows desktop environment — either a Duvo-managed cloud sandbox or your own Windows machine via RDP. See Computer Use.
  • Automates any Windows application regardless of whether it has an API or a web UI.
  • Works with installed desktop software, SAP GUI, Citrix, and Windows-only ERPs.
  • Slowest pattern; screen-reading adds latency.
  • Best for desktop applications that cannot be reached any other way.
Receive structured input from external systems through email attachments, file drops, webhooks, or Duvo’s Intelligent Document Reader. Examples: invoices arriving by email, reports uploaded to a shared folder, form submissions.
  • Passive intake — the external system pushes data to Duvo rather than Duvo polling.
  • Often paired with another pattern to take action after the intake step.
  • Best for document-heavy or event-driven workflows where a human or system sends Duvo something to process.

​
Decision Tree

Answer these questions in order. Stop at the first match. 1. Is the system already in Duvo’s connections catalog?
  • Yes → Use Pattern 1 (Hosted Connection). Connect it from the Connections page and move on.
2. Does the workflow start when someone sends Duvo a file, email, or document?
  • Yes → Start with Pattern 5 (Event and File Intake), then chain to Pattern 1 or 3 for downstream actions.
3. Is the target system a Windows desktop application (no web UI, no API)?
  • Yes → Use Pattern 4 (Computer Use / Windows Remote Desktop).
    • Need access to your own installed software or internal network? Use Windows Remote Desktop.
    • Need a clean sandbox without your own infrastructure? Use Computer Use.
4. Do you control the target system’s API and have technical resources to build a server?
  • Yes → Use Pattern 3 (Custom MCP). You get the most reliability, the most control, and the cleanest tool interface for your agents.
5. Does the target system have a web UI that a human can log into?
  • Yes → Use Pattern 2 (Browser Automation). Store credentials as a Login in Duvo and point the agent at the site.
6. None of the above fit?
  • Contact Duvo support to discuss whether a new hosted connection can be added to the catalog.

​
Trade-offs at a Glance

​
When to Combine Patterns

Most real-world workflows use more than one pattern. The common combinations:
An order form or legacy portal doesn’t have an export API, so the agent reads it via browser automation (Pattern 2). It then writes the extracted data to a CRM using a hosted connection (Pattern 1). This is common in procurement and logistics workflows.
A supplier emails an invoice as a PDF attachment. The agent reads it with Intelligent Document Reader (Pattern 5), extracts line items, then posts the result to NetSuite or SAP using a custom MCP server (Pattern 3).
A Windows ERP like SAP GUI holds operational data with no API surface. The agent logs in via Windows Remote Desktop (Pattern 4), extracts the data, and writes a formatted report to Google Sheets using a hosted connection (Pattern 1). This is the standard pattern for SAP reporting workflows.
Inbound customer requests arrive by email. The agent reads the email via Gmail (Pattern 1 — hosted), classifies the request, updates the relevant record in Salesforce or HubSpot (also Pattern 1), and sends a reply. No additional patterns needed because everything is in the catalog.
An internal system exposes a partial API. The agent reads structured records from it via custom MCP (Pattern 3) and then uses browser automation (Pattern 2) to submit those records into a legacy web portal that accepts no API calls.

Connections Overview

How connections work in Duvo

How to Add a Connection

Step-by-step for hosted connections

Building Custom Connections

How to build and deploy your own MCP server

Custom MCP

Connecting a custom MCP server to Duvo

Computer Use

Desktop automation options

Logins and Secrets

Storing credentials for browser automation

Intelligent Document Reader

Extracting structured data from documents