Any connection between your ERP and WhatsApp boils down to three paths: direct database read, the ERP's official REST API, or an MCP layer that abstracts the previous two. This post explains all three in plain language and helps you pick the one that fits your case.
The technical call usually takes five minutes once someone knows the three paths. What tends to stall the conversation is that the IT team thinks about only one (the one they've already used) and dismisses the others without comparing. It's worth reviewing all three options to avoid choosing the wrong one out of habit.
The scenario
A LATAM company with a standard ERP — Microsip, Defontana, Aspel, Tango, Bind, Alegra, SAP Business One, Odoo, or something built in-house. Operations want an AI agent to handle WhatsApp Business by reading and, in some cases, writing ERP data. Typical cases: collections, balance lookups, payment promise registration, sales briefing.
The question isn't whether it can be connected — it always can. The question is which way, with what implementation cost and what happens when the ERP changes.
Before reviewing the three paths, one principle: the integration is defined by your ERP, not by the AI tool. A serious AI agent tool supports all three paths and picks the one that works for your case. A rigid tool asks your ERP to fit its path — which usually means migration or rewrite.
Path 1 — Direct database
The simplest one when you have access. The AI agent connects to the ERP database with a read-only user and queries the tables it needs: customers, invoices, payments, salespeople, products. Queries are standard SQL, data arrives in real time, no intermediate layer to maintain.
When it fits. On-premise ERP or in a VPS with controlled DBA access. A company with an IT team that knows the schema. ERPs without API or with limited API. Reasonable transaction volume (millions of rows no, hundreds of thousands yes).
How it's implemented. Three steps:
- Create a read-only user on the database. No write permissions, no access to unnecessary sensitive tables.
- Build views (
VIEWin SQL) over the critical tables — customers, invoices, payments. Views insulate the agent from ERP schema changes and allow filter logic (excluding inactive customers, summarizing partial payments). - Configure the agent to query against the views, not directly against the tables.
Advantages. Speed of implementation. Real-time data. No dependency on the ERP vendor's roadmap. Works with any ERP that has an accessible database.
Disadvantages. If the ERP changes schema, you have to update the views. Doesn't work if the ERP vendor blocks external database access (some SaaS do). Requires someone with SQL on the implementation team.
Path 2 — The ERP's official REST API
Use the API the ERP exposes for external integrations. Each ERP that has an API documents its endpoints — GET /invoices, POST /payments, GET /customers/{id} — and the agent consumes them like any other integration.
When it fits. Cloud ERPs with documented REST APIs. Defontana, Alegra, Bind, Tiendanube, Odoo, Holded are typical examples. Also Microsip when operations run on its cloud version.
How it's implemented.
- Request API credentials from the ERP vendor. Usually a token or a client_id/client_secret pair. Some vendors charge for API access, others include it.
- Identify the relevant endpoints for the processes to automate. Not every ERP exposes everything — some only have an API for invoices, not payments.
- Configure authentication, pagination and rate-limit handling in the agent.
- Test against a sandbox environment when the ERP provides one.
Advantages. Stability in the face of internal ERP changes. The vendor maintains backward compatibility. Official documentation. Vendor support if something breaks.
Disadvantages. Not all LATAM ERPs have APIs. Those that do don't always cover every case (you may have an endpoint to read invoices but not payments). Some charge for API usage. Rate limits can be tight.
Path 3 — MCP (Model Context Protocol)
The open standard Anthropic published in 2024 so language models can connect to external systems through a common layer. Instead of each AI agent having its own integration with each ERP, an MCP server sits between the agent and the ERP and exposes standardized "tools" ("look up invoice", "record payment", "find customer").
When it fits. Companies with several ERPs or systems they want to query from the same agent. Companies that plan to add more agents and want a single integration layer. Custom ERPs where it makes sense to build the layer once and reuse it.
How it's implemented.
- Identify which tools the agent needs — "look up invoice by number", "list overdue invoices", "record payment promise".
- Build an MCP server that exposes those tools. Internally, each tool queries the database or the ERP API — but the agent doesn't see that difference.
- Connect the AI agent to the MCP server as a standard integration.
Advantages. A single integration layer for multiple agents. If the ERP changes, only the MCP implementation changes — the agents don't notice. Standardization: if you switch ERP in the future, you only rewrite the MCP, not the agents.
Disadvantages. More complex than the previous two paths. Requires building and maintaining the MCP server. Only pays off the complexity at scale — a single agent against a single ERP doesn't justify the overhead.
How Pacunex connects to any ERP
The strategy is pragmatic: we use the path that fits your case, not the one we have pre-defined. If your ERP has a documented REST API, we use it. If your ERP is on-premise with an accessible database, we read the database. If your ERP is custom or you plan to add more agents, we set up MCP.
The specific connector is built by the Pacunex team during the rollout, with your IT team involved only on the access side. It is not a form-based onboarding; it's construction work with two technical people.
For specific cases there are dedicated posts: AI agent for Microsip, AI agent for Defontana. And the list of integrations we already have solved lives in AI agents by ERP.
Typical cases
ERP on a VPS with SQL Server or PostgreSQL. Path 1. Materialized view over the receivables tables. Implementation time: days, not weeks.
Cloud ERP with documented REST API (Defontana, Alegra, Bind). Path 2. API credentials, sandbox testing, endpoint validation. Similar timeline.
In-house or highly custom ERP. Usually Path 3 (MCP) if multiple agents are planned. Path 1 (direct database) if it's a single case.
ERP with no external access. Rare but exists. A local agent syncs a data subset to an accessible intermediate database. It works, it's not ideal, but it exists.
What to do if something goes wrong
The ERP doesn't allow external reads. Check whether there's a cloud version, a higher plan with API, or an option for local replication. If no option exists, evaluate scheduled sync.
The API has very low rate limits. Cache queries, batch operations, schedule management across distributed time windows.
Schema changes break the integration. If the integration goes through views, update the view. If it goes through API and the vendor changed endpoints, read the changelog and adjust.
Slow performance on bulk queries. Move heavy logic into materialized views or into the MCP layer. Prevent the agent from repeatedly querying the same data.
Integration security
Whichever path you pick, four security principles always apply.
Dedicated user with minimal permissions. The agent never uses human credentials or service accounts with broad permissions. A dedicated user, read-only on what's needed, no access to unused tables.
Encrypted connections. TLS on REST APIs, SSL/TLS connections on databases. No exceptions, even if the ERP lives on the same corporate network.
Auditable logs. Every query the agent makes against the ERP is logged. Who (which agent, which customer it was serving), when, what it queried, what it got back. That supports audit responses and problem diagnosis.
Credential rotation. Tokens and passwords rotate at the cadence defined by the company's security policy. The integration must support rotation without falling over.
How to measure if it's working
Operational KPIs to validate the integration in production:
- Average query latency. If the agent waits five seconds to know a customer's balance, the conversation feels robotic. The sane target is below one second on routine queries.
- Query error rate. Ideally zero. Any error that reaches the end customer is a problem, because it breaks the customer's trust in the company.
- Data freshness. How much time passes between a payment hitting the ERP and the agent seeing it. In most operations, 1-2 hours is enough not to bother a customer who already paid.
- Query volume. To size the API rate limit or the database load. A well-designed operation caches the stable parts and queries only what's needed.
Common mistakes when planning the integration
Starting with the tool, not the case. If the conversation kicks off with "we want to use MCP", it's wrong. It should kick off with "we want to automate collections for 1,500 monthly invoices". The tool comes out of that.
Underestimating the lead time to obtain access. Especially with cloud APIs that require an internal process on the ERP vendor's side. Start the access request on day one, not halfway through.
Not involving the IT team from the start. If the IT team learns about the project once it's already approved, they tend to raise legitimate technical resistance. Better to include them in the decision.
Accepting dirty data without cleanup. The agent reproduces the ERP's errors. If there are duplicate customers, invalid phone numbers or invoices with incomplete data, the first step of the project should be cleanup.
Next steps
Tell us about your ERP on WhatsApp and we'll tell you which path fits in your case, before any commitment. The conversation is technical, not commercial: if the cleanest path is one you can already handle internally, we'll say so.