Admin API

Get a key, call the API

The Admin API manages catalogue, orders, customers, and store configuration for back-office tooling. This page covers the two things you need before writing any code: getting an Application Key, and how to send it. Every endpoint's full field-level reference is at /docs/admin.

1. Create a key 2. Call the API 3. Pagination & errors 4. Explore live

1Create an Admin Application Key

Keys are created in Backoffice - there is no API call that mints one for you.

  1. In Backoffice, go to Settings → Application APIs (/settings/api).
  2. Click Create Application API.
  3. On the Basics tab, choose the store this key belongs to and set Application Type to Admin.
  4. On the Access Control tab, save with every Scope checkbox left unchecked.
  5. Save. The plaintext key is shown once, right after creation - copy it now. Only a masked preview is shown afterwards (regenerate from the same screen if you lose it).
Leave the Scopes checkboxes unchecked when creating an Admin key. That list is the Store API's permission set (cart, checkout, wishlists, and so on) - it has no effect on what an Admin key can do, and ticking boxes there can leave the key unable to call anything. Admin keys are unrestricted by default; there's currently no Backoffice UI for scoping one down further.

Unlike Store keys, there is no "publishable" variant for Admin - every Admin key is a secret, server-to-server credential. Never embed one in a browser, mobile app, or anywhere a customer could read it: a request carrying a browser Origin header is rejected outright, key or not.

2Call the API

Base URL for every Admin endpoint: /api/v1/admin/...

curl https://your-store.example.com/api/v1/admin/sales/orders \
  -H "X-Commerce-Key: sk_admin_yourstore_<secret>"

X-Storefront-Application-Key also works, as a legacy alias for the same header. That's the whole auth story for an Admin Application Key - the store you're calling on behalf of is already embedded in the key itself, so no separate store header is needed.

The Application Key is the only credential you need. It identifies the store, so there is no separate store header and no token to exchange it for first. The only other schemes this API accepts are DTF and Central, both used by internal OrderEazi systems and not obtainable outside them.

Coming from the older api/ surface? That one also accepts HTTP Basic (an Auth0 username and password) and a Token-scheme JWT. Neither works here. Issue an Admin Application Key for this API and send it as above. Your existing integration keeps working against api/ until you are ready to move.

3Handle pagination and errors

Pagination

List endpoints read paging from request headers and return it in response headers:

HeaderDirectionMeaning
X-Page-NumberRequest & response1-based page number (defaults to 1)
X-Page-SizeRequest & responseItems per page (default 50, max 100)
X-Page-CountResponseTotal number of pages
X-Page-TotalRecordsResponseTotal matching records
curl https://your-store.example.com/api/v1/admin/sales/orders \
  -H "X-Commerce-Key: sk_admin_yourstore_<secret>" \
  -H "X-Page-Number: 2" \
  -H "X-Page-Size: 25"

Errors

Expected failures come back as RFC 9457 Problem Details, same shape as the Store API:

{
  "type": "https://…",
  "title": "Bad Request",
  "status": 400,
  "code": "…",
  "detail": "…",
  "traceId": "00-abc123…"
}

All Admin traffic shares the same 200-requests-per-minute-per-key limit as the Store API. A 429 comes with a Retry-After header.

4Explore and test everything live

The full reference - every endpoint, every field - is at /docs/admin.

Click Authorize at the top of that page and paste in your key - every "Test Request" button then fires a real call using it, so you can try an endpoint before writing any code against it.