
Integrate AI With Nuvemshop, Tray or Shopify: What Each API Allows
Compare what the Nuvemshop, Tray and Shopify APIs let you read and write on orders, products and stock, and start integrating AI with read-only access.
Want to apply this in your company?
Book a call with Juan →Integrate AI With Nuvemshop, Tray or Shopify: What Each API Allows
To integrate AI with Nuvemshop, Tray or Shopify, the safe path is the platform's official API, with a minimum-scope credential, starting with read-only access to orders, products and stock. All three platforms let you read and write those resources, but each handles authentication, permissions and limits in its own way, and that determines what an agent can do without supervision.
Key takeaways
- The AI does not connect to the store on its own. It calls the API through tools that you define and limit.
- Orders, products and stock can be read and changed on all three platforms, but the level of detail, the scopes and the usage limits vary and should be checked in the official documentation.
- Start with read permissions. Write access comes only after the agent proves it understands the workflow, and even then with human approval.
- Customer data in orders is personal data. Apply minimization, masking and the rules of LGPD (Brazil's data protection law) before sending anything to a model.
- Test with a development store or simulated data before touching the real store.
What does it mean to integrate AI with an online store?
In practice, the language model does not access Nuvemshop, Tray or Shopify. Your code, an automation workflow or a tool server does, using a credential issued by the platform. The model only decides which tool to call and with which parameters, and it receives the result as text.
This is good news for the person making the decision. Everything the agent can do in the store is exactly what your tools and the credential allow. If the tool only looks up the status of an order, the agent cannot cancel anything, no matter how much a customer asks or how hard a malicious piece of text tries to push it.
So the right question before any project is not which model to use. It is: what does my platform's API let me read and write, and what do I want the agent to read and write? Anthropic publishes useful guidance on designing clear, narrow tools for agents.
What does each API allow you to read and write?
The three resources that matter most for operations are orders, products and stock. Below is a general outline of what the official documentation describes. Field details and limits change over time, so treat this section as a map and confirm each endpoint in the documentation before you build.
Shopify:
- It has the Admin API, with GraphQL as the main interface, covering orders, products, variants, customers and inventory.
- Stock is handled per inventory item and per location, which helps anyone with more than one stock point.
- Each resource has separate access scopes for reading and writing. Older orders and certain customer data require additional permissions and fall under customer data protection rules.
- Webhook subscriptions exist for events such as order creation, which avoids polling the store all the time.
Nuvemshop:
- The REST API covers orders, products, variants, categories and customers, with separate read and write scopes per resource.
- Stock is tied to product variants, so updating stock usually means changing the variant.
- Webhooks exist for store events, such as orders created or paid, and the documentation describes request limits that your code has to respect.
- Authorization happens when the merchant installs your app and grants the scopes it asks for.
Tray:
- Tray's REST API covers products, orders, customers and stock information, and it is widely used by integrators and ERPs in Brazil.
- Access uses the application's credentials plus a store authorization code, which is exchanged for an access token. Tokens expire and must be renewed, so your workflow has to plan for that.
- Check Tray's developer documentation for how event notifications work and which order and stock fields are writable on the plan of the store in question.
The useful comparison is not which platform is better, but where each one demands the most care. On Shopify, the watch point is usually scope and customer data protection. On Nuvemshop, it is the merchant installing the app and the request limits. On Tray, it is the token lifecycle and the differences between stores.
How does authorization work on the three platforms?
Shopify and Nuvemshop follow the model of an app installed by the merchant, with explicit consent to the scopes. This is the OAuth design: the merchant sees what the app is asking for and approves it. Tray uses its own flow of credentials plus an authorization code, with a token that expires.
For your project, this leads to three practical decisions:
- Ask only for the read scopes you need at the start. Requesting write access just in case is the most common mistake and the most expensive to undo.
- Keep tokens and secrets in a vault or a protected environment variable, never in the prompt, in a spreadsheet or in a workflow visible to the whole team.
- Separate the agent's credential from people's credentials. If something goes wrong, you can revoke one without taking down the other.
The OWASP authorization guidance sums up the principle well: deny by default and grant the minimum necessary, checking permission on every action.
Why start with read-only access?
Reading lets you validate three things with no risk to the customer: whether the agent understands the store's data, whether its answers are correct, and whether the volume of calls fits within the API limits. A read error produces a bad answer that a human can correct. A write error produces wrong stock, a cancelled order or a changed price, and by then the damage has reached the customer.
There are good read-only use cases. Answering questions about order status and delivery time, helping the team find products and variants, summarizing problem orders for the operations team, and flagging when an item is low on stock. That list covers much of what AI customer support can automate safely.
Illustrative scenario: an accessories store gets many WhatsApp questions like "where is my order?". The agent has a single tool that looks up the order by number and the email provided, and returns only status, tracking code and estimated delivery. It does not see the full address, tax ID or purchase history. If the customer asks for an exchange, cancellation or refund, the agent records the reason and hands off to a person. For a few weeks the store measures how many conversations were resolved without help and how many handoffs had enough context. Only after that does it discuss whether to allow some write access, such as an internal note on the order. To connect this flow to the channel, see how to integrate AI into your company's WhatsApp.
What is the step-by-step plan for a safe start?
Use this sequence for any of the three platforms.
- Step one, map: write down the current workflow as it really is. Who asks, where the answer lives today, who decides, how long it takes. Without this starting point, there is no way to know whether the AI improved anything.
- Step two, pick a single workflow: for example, order status lookup or product availability check.
- Step three, list the minimum data: which fields the agent needs to see. If it does not need the tax ID, the tool should not return it.
- Step four, create the read-only credential: check the exact scopes in the documentation and request only those.
- Step five, build narrow tools: one function per task, with validated parameters, not a generic API call that accepts any route.
- Step six, test outside the real store: use a development store or simulated responses. The article on mock tools and sandbox testing for AI agents explains how.
- Step seven, log everything: every call, its parameters, a summary of the response and the agent's decision, with a date. Without logs, there is no audit and no improvement.
- Step eight, define the success and stop criteria before switching on: what working well means and in which situation the pilot is halted.
- Step nine, decide: expand, adjust or stop. Only then consider a write action, with human approval in the first phase.
Which risks need attention, and how do you handle them?
Personal data. Orders carry name, address, phone and tax ID. That is personal data under LGPD, and sending it to a model hosted outside the country may count as an international transfer. Minimize what leaves the store, mask what is not needed, and read what LGPD requires for international data transfer when using AI. Brazil's data protection authority (ANPD) is the official reference for guidance.
Untrusted text inside the data. Customer notes on the order, messages and product descriptions are text that the model will read. Someone can plant a disguised instruction there. The agent should not have tools that cause harm if they obey that text, which is why starting with read-only access helps. OWASP maintains specific material on prompt injection prevention.
Usage limits and repetition. APIs limit the pace of requests. An agent stuck in a loop can exhaust the store's quota and disrupt the site itself or ERP integrations. Set a ceiling on calls per conversation and per period, and handle errors with controlled retries.
Writes without idempotency. When it is time to write, a repeated call must not duplicate the effect. Stock adjustments are the classic example: applying the same deduction twice creates a discrepancy that is hard to find. Prefer operations that set a known value over operations that blindly add or subtract, and require human confirmation at the start.
The working method follows four moves: map the current process and the starting point, limit the agent's data and actions, pilot one real workflow with logs and an agreed metric, and hand the operation over to the team, then decide whether to expand, adjust or end it. Applied to an online store, this means not enabling write access before reading has been measured.
Frequently asked questions
Does the AI need full access to my store to be useful? No. Most first use cases work with read access to orders and products, and a subset of fields. The less the credential can see, the smaller the possible damage if something goes wrong.
Can I let the AI change stock and prices on its own? Technically, the APIs usually allow it once the write scope has been granted. In practice, it is not a good starting point. Begin with suggestions that a person approves, and automate only after you have logs, limits and a clear way to reverse the change.
Which platform is easiest to integrate: Nuvemshop, Tray or Shopify? It depends more on your context than on the platform. Check each one's official documentation for the exact feature you need, such as order events or stock by location, and consider who already maintains integrations on your store, such as the ERP and payment gateways, to avoid data conflicts.
Do I need a developer, or can I use automation tools? For reading and simple workflows, automation tools with a restricted credential are usually enough. When there is write access, approval rules, data masking and your own logs, it is worth having code under the company's control. In either case, who is responsible for the credential and for reviewing the logs should be defined before you switch on.