---
title: "How to connect an AI agent to your legacy ERP without an API"
description: "Exports, read-only access, RPA and web-to-API layers: how to choose a connection for your legacy ERP and test it with limited permissions."
author: "Carlos García"
published: 2026-10-26
updated: 2026-10-26
verified: 2026-10-26
language: en
human_url: "https://kiia.cloud/blog/connect-ai-agents-to-legacy-erp-without-api/"
---

> **In 60 seconds:** To connect an AI agent to an ERP without an API, first identify what you can read with authorization: a report, a data view or a screen. An export may be enough if its cutoff time is acceptable. If you need to query a web interface, compare RPA with a layer that exposes specific operations as an API or MCP tools. Start with a dedicated read-only account and one workflow, such as checking orders. Measure accuracy, data age, failures and supervision work. Pomerado is an example of the web-to-API category; its documentation does not establish that it works with your ERP.

Imagine a small distribution business whose legacy ERP still records orders. The team wants to ask “what is the status of this order?” without searching through screens. Before choosing an agent, you need to know how it can retrieve that status and check that it belongs to the right order.

Connecting a legacy ERP to AI starts with that access route. The agent needs a narrow operation: it takes an identifier and returns a status, a source reference and a retrieval time. This workflow does not require creating orders or changing inventory. If sales follow-up is also missing, separate responsibilities as we explain in [your ERP does not have to be your CRM](/blog/erp-does-not-have-to-be-crm/).

## Which connection can you use?

First ask the ERP vendor whether your version and license include a supported connector, an integration module or scheduled reports. “We don't use it” and “it doesn't exist” lead to different decisions. Also establish whether the application is a desktop client, has a web interface or allows authorized access to its data.

The table moves from a limited copy toward operations on the system. Risk depends on permissions and the workflow: an official read-only connector may be safer than a file containing every customer's details. Effort is relative and needs validation in your installation.

| Route | When it fits | Relative effort | Fragility | Risk to control |
| --- | --- | --- | --- | --- |
| CSV, Excel or report exports | You can wait for the next data cutoff | Low if the report exists; higher if export automation is needed | Changed columns, incomplete files or missed exports | Excessive data copies and stale answers |
| Read-only database or replica with restricted views | You need structured queries and have authorized access | Medium; depends on technical support | Schema changes and field semantics | Exposing too many tables or loading the operational server |
| Browser automation, RPA or computer-use agent | The interface is the only available route | Medium to high depending on screens and exceptions | Interface changes, unexpected windows and expired sessions | Wrong clicks and inherited user access |
| Web-to-API/MCP layer | A web portal and repeatable operations are available | Medium; authentication and each operation need validation | Still depends on the portal even when it hides its screens | Credentials in another layer and broader actions than intended |
| Vendor connector or custom integration | A supported route exists or someone can maintain an adapter | Variable; usually increases with custom development | Versions, data contracts and maintenance | Excessive permissions or writes that bypass validation |

### Exports: query a dated copy

A scheduled order report can feed the agent without opening access to the ERP. Keep the order ID, status and cutoff time; exclude fields the query does not need. Validate headers, row counts and freshness before accepting each file. If an expected export is missing, the agent must flag stale data and hand off the query.

This route fits summaries or queries that tolerate a delay. It cannot support a promise of current stock from yesterday's file. Define who delivers the report, where it is stored and when it is deleted. If the process includes rekeying data, measure it using the guide to [the cost of copying data between systems](/blog/cost-of-copying-data-between-systems/).

### Database access: prepared, read-only queries

If the vendor authorizes access, a view can expose only orders within the agreed scope. A technician must verify what each status means and how to limit queries, rows and load. The agent calls a prepared query with validated parameters; it does not get freedom to run arbitrary SQL. A replica can isolate some load, but its lag needs review. Replica design or a migration decision requires a separate assessment; here we are identifying an access route.

### Screens: distinguish RPA from computer use

RPA follows a prepared sequence of actions. A computer-use agent can decide steps from what it sees. Both need to detect expired sessions, empty results and unexpected screens before proceeding. Microsoft's automation documentation distinguishes [desktop and web UI elements](https://learn.microsoft.com/en-us/power-automate/desktop-flows/ui-elements): a Windows application and a browser portal require different mechanisms.

Test ID searches, pagination and permissions with fictitious data. A robot reading the wrong row can return a convincing answer. If it cannot confirm the identifier, it must stop. When the ERP has only a desktop client, evaluate desktop RPA; a tool designed for websites does not automatically cover that interface.

### Web to API/MCP: a defined operation over the portal

This layer turns a web journey into an operation with defined inputs and outputs, such as `check_order(id)`. The agent can call it as an API or an MCP tool, the protocol connecting agents to tools. Automation still depends on the website and its authentication. “Deterministic” describes a defined execution; it does not guarantee correct data or an interface that never changes.

It fits when the ERP or portal has a web interface, allows automation and lets you restrict the account to necessary records. Test login, 2FA, session expiry and filters in your installation. It does not fit a desktop-only client or a SQL-only access route, or sensitive data transfers without acceptable safeguards. Displaying a remote desktop in a browser tab does not establish compatibility either.

### Supported connector or custom adapter

If a compatible connector turns up, check its operations, license, authentication and actual permissions before building another. Request a test on the same ERP version. A custom adapter lets you define a narrow query over an authorized access route, but needs an owner, documentation and maintenance when the system changes. Inventing an API that writes directly to internal tables can bypass ERP rules: any future write must use a supported, validated mechanism.

## Pomerado as an example, with verifiable limits

Sources checked on **October 26, 2026**. [YC lists Pomerado](https://www.ycombinator.com/companies/pomerado) as an active Fall 2026 company. Kiia has no commercial relationship with it and has not tested the tool. We include it to explain a category.

According to its [official repository](https://github.com/Pomerado/pomerado), it generates deterministic integrations for websites, including pages with login and 2FA. Its core is MIT-licensed and can be run yourself; that does not provide the entire Cloud service operation. Its [connection guide](https://docs.pomerado.ai/getting-started) documents MCP and REST API access.

Its [commercial website](https://pomerado.ai/) advertises hosting and automatic repair. These are vendor-stated capabilities to test with your portal. List prices checked that day: Free, USD 0/month, 100 calls/day and 10 new integrations/month; Premium, USD 50/month, 1,000 calls/day and 100 integrations/month; Business, contact the vendor. Reconfirm terms before purchasing.

We do not apply its comparative speed, cost or reliability figures to your ERP. The documentation does not establish compatibility with your installation or an independent security and privacy audit. An open core helps with exit planning; operating it yourself requires maintaining infrastructure, authentication and integrations.

## Risks to resolve before connecting

ERP credentials, session cookies and 2FA mechanisms allow actions under the assigned identity. If a third party is involved, verify what it receives, where it stores it, who can use it and how you revoke access. Review account recovery and deletion at the end as well. The guide to [credential custody and electronic signatures](/blog/electronic-signature-credentials-ai-agents/) develops this boundary for portals.

Ask the vendor to confirm whether the ERP contract and terms allow this automation. Review usage limits and support; being able to sign in does not establish contractual permission to automate. For personal data, mark applicable rules, transfers, processors, retention and sector obligations as **verify for each country**. The decision needs local review before sending real information.

A screen change can break a search or silently alter its results. Record the integration version, validate IDs and stop the workflow on discrepancies. If a layer “repairs” itself, recheck its scope before using it. After a timeout during a future write, query the actual state before retrying: repetition could duplicate an order or payment.

You also depend on whoever maintains the connection. With a recent provider, request an exit plan: what code and data your plan lets you export, which secrets need rotation and who can restore the manual procedure. Rehearse the alternative before depending on it.

## Minimum controls for the first workflow

- Create a dedicated read-only agent account restricted by company, records and fields. The ERP or connector must enforce this limit. If it cannot, narrow the scope to a controlled export or stop the trial.
- Begin with fictitious data and test refusals too: another customer, another company, an unknown ID and a request to make a change.
- Log the actor, order ID, time, source date, version and result or error for every call. Avoid recording passwords, 2FA codes or full copies of personal data.
- Keep every write behind human approval of the exact change, with duplicate protection and recovery tested before enabling it.
- Assign an incident owner, a way to revoke access and a manual exit procedure.

Expand this framework with [secure agent permissions for a small business](/blog/secure-ai-agent-permissions-small-business/). Enforce limits outside the model; a chat instruction cannot replace a technical permission.

## A one-week trial: check order status

Use one week as a bounded observation period. It cannot demonstrate every production scenario. Choose an owner and document which data the agent may see and how old an answer may be.

1. On day one, map the current query: input ID, source screen or report and expected answer. Measure manual handling time and agree on conditions for stopping the trial.
2. On day two, choose one route from the table and prepare the restricted account or file. Verify terms of use and the data path before connecting it.
3. On days three and four, test fictitious orders: open, partial, cancelled, missing and outside the permitted scope. Include an expired session, a stale file or a changed screen, depending on the route.
4. On day five, if controls pass, compare an authorized sample with the source under human supervision. Each answer must show the ID, status and retrieval or cutoff time. If it cannot validate the data, it must hand off the case.
5. At the end of the week, review matches, refusals and failures with the person doing the queries. Decide whether to continue read-only, fix the connection or stop it. Expanding to writes requires its own assessment.

Measure ID and status matches across reviewed queries, data age, completed queries, failures and handoffs. Separate waiting time from human time spent checking results and maintaining the connection. Record actual tool and support costs. If you need acceptance thresholds, agree on values before the trial; a week with few orders does not demonstrate ROI.

The [executive assistant connected to ERP, sales and collections](/blog/ai-executive-assistant-erp-sales-collections/) describes other query uses. If you receive documents instead of structured records, review [invoice and document data extraction](/blog/ai-data-extraction-invoices-customs-documents/) before treating a PDF as an ERP connection.

To assess a first query, you can [book a diagnostic call with Kiia](https://cal.kiia.cloud/team/kiia-cloud/discovery-call). Bring the ERP name and version, the access routes its vendor allows and a fictitious example of the result you need.

## Frequently asked questions

### Can I connect an AI agent to an ERP without an API?

You can provide access through scheduled exports, read-only database views or interface automation. If it has web screens, you can also evaluate a web-to-API/MCP layer. The choice depends on authorized access, data freshness and the permissions your ERP lets you restrict.

### Does a web-to-API tool work with a desktop ERP?

It needs a compatible web interface. A desktop client or a SQL database without web screens requires another route, such as exports, controlled queries or desktop RPA. Seeing a remote desktop inside a browser does not establish compatibility.

### When should I let the agent write to the ERP?

After validating reads and testing each operation in a test environment. Before enabling writes, require specific permissions, human approval of the exact change, logging, duplicate protection and a recovery procedure. A successful read-only pilot does not automatically authorize writes.