Admin API

Why it matters

The Admin API is where every automation a merchant eventually wants gets built: syncing stock from a warehouse, generating products from a supplier feed, pushing orders into accounting, bulk-editing a catalogue nobody wants to edit by hand.

It is also the API that can do damage. A token with write scopes can delete products, cancel orders, and rewrite inventory, which is why it must stay server-side and why scope discipline matters more here than anywhere else on the platform. A great deal of integration security comes down to requesting read access when read access is what the job needs.

The practical consequence for a growing store is that Admin API work is the difference between operations that scale and operations that hire.

How it works on Shopify

GraphQL is the supported surface, and REST is being retired — new work should assume GraphQL. Authentication is by access token, obtained through OAuth for a public app or generated directly for a custom app installed on one store.

Scopes are granted per resource and per direction, so an integration that reads orders and writes fulfilments asks for exactly those. Adding a scope later means reinstalling the app, which is worth knowing before launch week.

Rate limiting is cost-based, drawing from a bucket that refills continuously, with a larger bucket on Shopify Plus. Sustained work is expected to run through the bulk operations API instead: you submit a query or a mutation set, Shopify processes it asynchronously, and you collect the results from a file. Anything touching thousands of records belongs there rather than in a loop.

Webhooks are the counterpart. The API is how you push changes in; webhooks are how you hear about changes out.

Common mistakes

• Calling it from a browser. The token is privileged. In client-side code it is public, and the store is one script away from a stranger.
• Requesting write scopes by default. Broad scopes make an eventual token leak far worse and are usually unnecessary.
• Looping instead of bulk. A script iterating ten thousand products will throttle, take hours, and fail halfway. Bulk operations exist for this.
• No retry with backoff. Throttled requests are normal operation, not an error state. An integration without backoff loses data silently.
• Ignoring version deprecation. API versions expire. Integrations built and forgotten stop working on a schedule someone should have in a calendar.
• Writing without idempotency. Retried mutations that create duplicate records are the classic production incident.

When you need help

The trigger is usually a script that has outgrown being a script — a nightly sync that now takes four hours, throttles, and fails without anyone noticing until stock is wrong.

The other case is scoping and security review before an integration goes live, particularly one built by a third party. Which scopes it holds, where the token is stored, and what happens when it is rotated are questions worth answering before the integration has write access to a live catalogue rather than after. Ownership of each field between Shopify and the connected system is the same design work described under API integration.