Magento and Adobe Commerce AI Agents: APIs and Permissions (2026)
Quick summary: Adobe Commerce still has no AgentCore connector. Use an integration's OAuth credentials against /rest/V1/, not a 4-hour admin password token. Reads first. Refunds stay with a person.
Key Takeaways
- Use an integration's OAuth credentials against /rest/V1/, not a 4-hour admin password token
- On 25 September 2026, "Magento AI agent" means an adapter in front of Adobe Commerce (or Magento Open Source) REST
- There is no Bedrock AgentCore app in the Marketplace that we are willing to call a connector
- Authentication you can defend Adobe's token authentication guide distinguishes: - Integration
- Activating an integration yields a consumer key, consumer secret, access token, and access token secret for OAuth 1

Table of Contents
On 25 September 2026, “Magento AI agent” means an adapter in front of Adobe Commerce (or Magento Open Source) REST. There is no Bedrock AgentCore app in the Marketplace that we are willing to call a connector. The shared boundary with other platforms is the integration post.
Who this is for. An architect on Adobe Commerce. Shopify-specific scopes are a different page.
Our take: an integration with a short resource list beats an admin user named agent. Refunds and credit memos stay out of the tool schema.
Authentication you can defend
Adobe’s token authentication guide distinguishes:
- Integration. Activating an integration yields a consumer key, consumer secret, access token, and access token secret for OAuth 1.0a. That is the server-to-server credential. The resources you tick at activation are the authorization boundary.
- Admin token.
POST /rest/{store_code}/V1/integration/admin/tokenexchanges a username and password for a bearer token. Adobe says the default lifetime is 4 hours, and admin accounts must use a two-factor provider. Some providers need more than one call. This is a bad robot identity. - Customer token. Default 1 hour, for a shopper. Do not reuse it as the agent’s identity.
Bearer tokens as a stand-in for OAuth can be turned on (Stores > Configuration > Services > OAuth > Consumer Settings). Adobe does not recommend that shortcut. Leave it off.
On Adobe Commerce as a Cloud Service, Adobe’s integration starter kit uses OAuth server-to-server credentials from the Developer Console. JWT service-account auth was deprecated in favor of OAuth. Do not ship a new JWT integration in 2026 because an old diagram shows one.
Base URL differs by product. PaaS looks like https://{host}/rest/. SaaS uses the Commerce API host Adobe gives that environment. Pin it. A tool that guesses /rest/V1 on a SaaS host will 404 and the model will invent the order.
What the tools may call
Named reads, store code explicit:
- Order by increment id
- Shipments for that order
- Stock for a SKU via the inventory API you actually enabled (MSI is not “the qty column” on every install)
- Product attributes you have typed, not the description HTML
Omit credit memo, invoice capture, and POST /V1/orders/{id}/cancel from the OpenAPI file the agent sees. If the integration token can still call them, the spec is a wish. Create a second integration with only the resources you listed.
Webhooks
Adobe’s webhook docs split by product. SaaS can subscribe in Admin or by REST, and does not implement every method. PaaS and on-prem declare hooks in module config, with auth headers you supply. Each request gets x-adobe-commerce-request-id. Use it in logs.
A webhook is a nudge to refresh a read model. It is not permission to email the customer or to refund. Verify the signature or OAuth header your environment configured before you parse the body.
Failure and approval
- 401 after four hours on an admin token means you used the wrong credential. Do not cache a human password to refresh it.
- Two store views, two prices. Pass the store code. Do not let the model pick the cheaper one.
- Inventory reservation versus salable qty. Return the field name. If you are unsure which module is authoritative, escalate. Do not subtract in the prompt.
- Partial shipment. Say what shipped. Do not average delivery dates.
What broke — An adapter used the admin token “temporarily” and stored it in the agent memory store so the next turn would not re-authenticate. Detection: memory traces contained a bearer token, and a second agent in the same account could read that memory. Fix: delete the memory record, rotate the admin user, switch to an integration. Lesson: tokens are not facts about the shopper. Keep them in a secret the model cannot retrieve.
Human approval for anything that moves money matches the rest of the field guide. Below 16 out of 30 on readiness, do not add writes.
If you only do one thing
Create an integration whose resource list is the five GET routes you can name. If you cannot name them, you are not ready to connect a model.
What to do this week
- Confirm PaaS versus SaaS. The webhook and auth screens differ.
- Mint an integration. Do not mint an admin token for the agent.
- Publish a tiny OpenAPI file with GETs only. Point Gateway or your MCP server at that file.
- Log
x-adobe-commerce-request-idnext to your trace id. - Compare notes with BigCommerce only for the shape (token, scopes, no raw admin). The headers are not interchangeable.
- Discuss the architecture via eCommerce AI agents or the AgentCore service if the runtime is the open question.
What this post doesn’t cover
- A module you can composer-require from us. This post does not ship one.
- B2B company credit inside Adobe Commerce B2B. That is a separate permission model; do not fold it into the first read agent.
- Migration off Magento 1. There is no supported API path we will recommend.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.




