Integrating AI with Brazilian ERPs via API: Bling, Omie and Tiny

Integrating AI with Brazilian ERPs via API: Bling, Omie and Tiny

The safest way to integrate AI with Bling, Omie or Tiny is to use the ERP's API through an intermediate layer that you control. That layer exposes only a few tools to the agent: reads are open, and writes are limited, validated or approved by a person. The AI helps interpret orders, messages and documents, but the write to the ERP is performed by a deterministic workflow with clear rules.

Key takeaways

• The agent should never receive the ERP credential or talk to the API directly. It calls tools you designed, and those tools enforce the rules.
• Start with reads (order lookup, stock, invoice status) and move to writes only later, always with a draft or human approval.
• Each ERP has its own authentication model, scopes, rate limits and fields. Confirm everything in the current official documentation before you design the flow.
• Actions that touch money, stock or invoices need idempotency, a decision log and a simple way to undo or correct them.
• A pilot with one real workflow, one owner and one agreed metric is worth more than a broad integration with no owner.

What does it mean to integrate AI with an ERP like Bling, Omie or Tiny?

Integrating AI with an ERP does not mean putting a language model inside the system. It means connecting software that interprets text and makes routine decisions to a system that holds the truth of your operation: orders, customers, stock, accounts receivable, invoices. The API is the door between them.

That changes the nature of the risk. A chatbot that answers wrongly causes a misunderstanding. An agent that writes wrongly to the ERP creates a duplicate order, an improper financial write-off or a corrupted customer record, and the damage spreads to accounting, shipping and support.

So the useful question is not "can the AI use the API?" It can. The useful question is "what can it do on its own, what needs approval, and what should it never touch?"

What paths exist for connecting AI to the ERP?

In practice there are four arrangements. They show up often in Brazilian companies that run small and midsize ERPs.

• Read-only lookup: the agent fetches an order, stock level, invoice status or the state of a receivable and answers whoever asked. This is the safest starting point.
• Deterministic workflow with AI in the middle: a traditional workflow (for example, triggered when an order arrives by email or spreadsheet) calls the AI only to extract and classify data, and the workflow itself validates and writes. The AI decides little, the workflow decides a lot.
• Agent with restricted tools: the agent chooses among tools such as "look up order" and "create draft order", each with validated parameters. More flexible, but it needs more control.
• Standardized tool layer: protocols such as the Model Context Protocol help expose tools to the agent in an organized way, but they do not replace permissions, validation and logging.

A simple rule helps you choose: the more irreversible the action, the closer you should stay to the second arrangement, where the workflow is deterministic. If you are still comparing orchestration tools, OpenClaw vs Zapier, n8n and Chatbots helps separate what is a fixed flow from what needs judgment.

What do the APIs allow, and where are the limits?

Bling, Omie and Tiny offer APIs for the most common records and movements: products, customers and suppliers, sales orders, stock, accounts payable and receivable, and invoice issuing or lookup. What differs between them, and what you must check in each vendor's official documentation, includes the following:

• Authentication: some ERPs use an OAuth flow with tokens that expire and must be renewed, others use fixed keys or tokens. This affects where you store the secret and how you rotate it.
• Scopes and permissions: check whether the credential can be limited to certain modules. If the credential is too broad, the restriction has to come from your intermediate layer.
• Rate limits: APIs usually cap the volume of calls. An agent that repeats lookups in a loop can exhaust the limit and block the rest of the operation.
• Write endpoints: not everything the interface allows is available through the API, and not everything the API allows is reversible. Confirm whether deletion, cancellation or reversal exists, and how each one behaves.
• Webhooks and events: when they exist, they beat repeated polling for knowing that something changed. Also check how to verify the origin of the notification, in the spirit of what Stripe's webhook documentation teaches about signature verification.
• Idempotency: if the API offers no idempotency key, you have to prevent duplicates yourself, for example by storing the external order identifier and checking it before creating anything. Stripe's explanation of idempotent requests is a good conceptual model, even though it comes from another provider.
• Test environment: see whether there is a test account or test company. If there is not, treat every write as production.

A note on data: orders and records contain customers' personal data. Before sending that content to a model, define what truly needs to go, mask what does not, and record the purpose. LGPD Compliance for AI on WhatsApp covers legal basis and records, and the same logic applies to data that comes from the ERP.

How do you stop the agent from taking wrong actions?

The most common mistake is handing the agent a broad credential and trusting the prompt to hold it back. Instructions in natural language are not access control. Control has to live outside the model, in the tool code and the permissions.

Some safeguards that work:

• Least privilege: the credential the agent uses reaches only what the flow requires. OWASP's authorization guidance describes this logic and the practice of checking permission on every request.
• Narrow tools: instead of one generic "call API" tool, build "look up order by number" and "create draft order". Anthropic recommends designing clear, focused tools, and that also reduces misuse.
• Validation in code: the type, range and existence of each field are checked before the call. The model proposes, the code decides.
• Human approval for high-impact actions: define a list of actions that always ask for confirmation. The AI agent approval policy template is a good starting point.
• Protection against malicious instructions: an email, an order note or a customer message can contain text that tries to manipulate the agent. Treat all external content as data, not as orders. OWASP's reference on prompt injection prevention details practical measures.
• Decision log: keep what the agent received, what it proposed, what was approved and what was written. Without it you cannot investigate an error or show what happened.
• Emergency stop: a simple switch that turns off writing without taking down reading.

Which actions can the agent do alone, with approval, or never?

A decision guide avoids long debates. Adjust the list to your operation, but keep the logic: the harder an action is to undo, the more control it needs.

• Allow on its own: look up orders, stock, delivery status and invoice status; list products; find a customer by tax ID or phone number for support.
• Allow as a draft: assemble a draft sales order, suggest a new customer record, prepare a stock update for review.
• Require human approval: confirm an order, change a price or discount, change existing customer data, issue or cancel an invoice, record a receivable settlement.
• Do not allow the agent: delete records, change tax settings, touch bank accounts, reconcile finances in bulk, change user permissions.

If your case is online store support, AI Customer Service for Ecommerce shows where order lookup alone already resolves a good part of the demand without any write access.

How do you build a pilot step by step?

The method we use follows four moves: map, limit, pilot and hand over. Applied to an ERP, it looks like this:

• Step 1, map: describe the current flow end to end, who does each step, which ERP screens are used and where errors happen today. Record a simple baseline, such as the time of one step or the amount of rework the team already notices.
• Step 2, limit data and actions: choose a single workflow. List the fields the model needs to see and the ones it does not. Define the tools, the allowed parameters and the list of actions that require approval.
• Step 3, prepare access: create a credential dedicated to the pilot, keep the secret out of the code and the prompt, and set up alerts for unusual calls. If the API has a test environment, start there.
• Step 4, build the tool layer: implement validation, a deduplication key, rate limit handling and logging of every call.
• Step 5, test with real cases and bad cases: duplicate order, customer without a tax ID, nonexistent product, a message with a suspicious instruction, API down. Check what the agent does when it does not know.
• Step 6, operate under supervision: run with a responsible person reviewing drafts and decisions. Define a success metric and a stopping criterion beforehand.
• Step 7, hand over and decide: give the team documentation, access and a review routine, then decide whether to expand, adjust or end the pilot. How to Measure an AI Automation Pilot goes into these decisions.

Illustrative scenario: orders received by message

Illustrative scenario: a small distributor receives orders from repeat customers by text message. Today, one person reads each message, checks the customer in the ERP, types in the items and confirms the order.

In the pilot, the agent reads the message and extracts the customer and items. A read tool confirms that the customer exists and that the products are in the catalog. A second tool creates only a draft order, using the message identifier as the deduplication key, so the same message processed twice does not produce two orders.

The agent never confirms the order. The responsible person opens a queue of drafts, sees the original text next to the proposed items, and approves or corrects. When a message is ambiguous, for example a product whose name resembles another, the agent does not choose: it flags the doubt and hands it back to the person. Every step is logged, and the pilot is judged by how many corrections the person had to make and by the review time.

If the entry channel is WhatsApp, combine this with a clear handoff design, as described in WhatsApp AI Agent Human Handoff.

What should you check before going live?

• The agent's credential is exclusive, with the least access possible, and the secret does not appear in a prompt, a log or a repository.
• Every write tool validates input, prevents duplicates, and records who asked, what was sent and what the ERP replied.
• The list of actions that need human approval is written down, and the agent cannot bypass it.
• There is a named owner, a channel for reporting errors and a switch to pause writing.
• Personal data sent to the model was reduced to what is necessary, with the purpose recorded.
• The team knows how to correct a wrongly written ERP record without depending on whoever built the integration.
• The pilot metric and the stopping criterion were agreed before starting.

When a company prefers not to run this layer alone, a design with permissions, restricted tools, observability and human approval can also be built with OpenClaw for Business, and the managed operation is delivered by Be Human.

Frequently asked questions

Can the same design be used for Bling, Omie and Tiny? Largely, yes. The tool layer, the approval rules and the decision log are the same. What changes is the adapter for each ERP: authentication, field formats, limits and the behavior of each endpoint, all of which should be checked in the official documentation.

Do I need a developer to integrate AI with the ERP? For simple lookups, no-code automation tools may be enough. For writes with validation, deduplication and logging, technical support is advisable, because the costliest errors sit in exactly those details. What matters is that someone in the company understands the flow and can maintain it.

Can the AI agent issue invoices or touch finance? Technically the API may allow it, but we do not recommend starting there. These actions are hard to reverse and carry tax and accounting consequences. If they ever enter the scope, they should require human approval and go through a separate pilot with their own criteria.

What should I do if the agent writes something wrong? Pause writing, use the log to find the source, and correct the data in the ERP through the company's normal procedure. Then adjust the validation or the approval rule that let the error through, and add the case to your tests. This cycle is part of operating the system, not an exception.

Sources

• OWASP: Authorization Cheat Sheet
• Anthropic: Writing effective tools for agents
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• Stripe: idempotent requests