Store API

A read-only REST API over this store's cart drawer data, for your own scripts, dashboards and integrations. Every endpoint is a GET, every response has the same shape, and each key belongs to one store.

If what you want is an AI assistant that can answer questions about the store, you want MCP instead. This surface is for code you write.

Create a key

1. In AOV.ai Cart Drawer, go to Settings, then the Store API tab.
2. Copy the Base URL.
3. Name the key after the integration it is for. 1–40 characters.
4. Click Create key.

The key is shown once, with a ready-to-run example underneath.

Your first request

curl "https://aov-cart-drawer.firebaseapp.com/store-api/v1/setup-health" \
  -H "Authorization: Bearer aov_sk_YOUR_KEY"

const res = await fetch(
  'https://aov-cart-drawer.firebaseapp.com/store-api/v1/analytics?start=2026-08-01&end=2026-08-31',
  {headers: {Authorization: 'Bearer aov_sk_YOUR_KEY'}}
);
const {success, data, error} = await res.json();

Every response has the same shape

{"success": true, "data": { }, "error": null}

On failure, success is false, data is null, and error carries a stable code:

{"success": false, "data": null, "error": {"code": "INVALID_INPUT", "message": "…"}}

Branch on error.code or on the HTTP status, not on the message. Codes and statuses are stable; wording is not. Both are listed in Errors.

The API describes itself

GET /store-api/v1 returns the endpoint list with each path, its summary and the query parameters it accepts. It is generated from the same table that builds the routes, so it cannot fall out of date with what exists. It needs a key, like everything under the prefix.

Never call this from a browser

The API sends permissive CORS headers, so a request from browser JavaScript will succeed. That is there for server-side tools and local development, not for your storefront.

Keys are per surface

Present an aov_mcp_ key here and the response says so by name — WRONG_SURFACE — rather than reporting it invalid, because the fix is to mint the right kind of key, not to hunt for a typo.

Losing the subscription revokes your keys

Every other refusal here is recoverable with the same key. This one is not, so an integration that retries through it will move from NO_PLAN to INVALID_KEY and stay there. Treat NO_PLAN as an alert, not as a backoff.

Nothing changes on the MCP side: connections there are refused while the subscription is gone and resume when it returns.

Limits

Rate limits are counted per key, so one integration cannot exhaust another's budget. Requests are counted before the key is resolved, so a flood of bad keys is throttled too.

What is never returned

• No customer data. No names, emails, addresses, or individual orders. Analytics figures are aggregates over a date range.
• No credentials or internal ids. The Shopify access token, the store's record id and the key's fingerprint are stripped before anything leaves the server.
• No write access. There is no POST, PUT or DELETE. Nothing you call can change a template, a setting or a subscription.

Where next

• Endpoints — all six, with their parameters
• Errors — every code, what causes it, what to do
• MCP tool guide — the meaning of the fields each endpoint returns