Admin API: The Shopware 6 Backend Interface for ERP and Automation

The Admin API is the interface used to manage Shopware 6 from the outside: you can read and write products, stock, orders, customers, and settings with it. It’s the standard way to connect ERP, PIM, CRM, and middleware to your store.

Anything you can do in the Shopware 6 Administration can also be done through the Admin API: create products, change stock levels, read orders, update customers, trigger status changes. The Administration itself is just a client of this API; every action in the backend is an API call.

That’s exactly why the Admin API is the standard way to integrate third-party systems. ERP, PIM, inventory management, CRM, and middleware talk to Shopware through this interface, usually in the background and without user interaction. It’s REST-based, returns JSON, and reaches every entity in the Data Abstraction Layer.

Shopware 6 provides two interfaces that are often confused:

• Admin API: for backend processes and system integrations. Full access within the assigned permissions, authentication via OAuth 2.0, endpoints under /api/.
• Store API: for customer-facing frontends such as the Storefront, apps, or headless stores. Works in the context of a sales channel and a customer, authentication via sw-access-key, endpoints under /store-api/.

Rule of thumb: what an employee does in the Administration belongs to the Admin API. What a customer does in the store belongs to the Store API. Our article on GraphQL and REST APIs in Shopware explains the differences in detail.

Access works via OAuth 2.0. For system integrations, go to Settings → System → Integrations, create an integration with its own role, and you’ll receive an access key ID and a secret access key. Use them to request a token:

POST /api/oauth/token
{
  "grant_type": "client_credentials",
  "client_id": "YOUR_ACCESS_KEY_ID",
  "client_secret": "YOUR_SECRET_ACCESS_KEY"
}

The token is valid for ten minutes and is sent as an Authorization: Bearer header. For tools that act on behalf of a user, there’s also the password grant type with a refresh token. Grant each integration only the permissions its process needs; with ACL roles, you can restrict access down to individual entities and operations. For background on the protocol, see the entry on OAuth.

• Read and write entities: GET /api/product, POST /api/product, PATCH /api/product/{id}, DELETE /api/product/{id}, and the same for orders, customers, categories, media, and all other entities.
• Search with criteria: POST /api/search/product with filters, sorting, pagination, aggregations, and associations. For example, this lets you load all orders from a given day, including line items, in a single call.
• Sync API: POST /api/_action/sync writes many records across multiple entities in a single request. It’s the right approach for stock and price updates involving thousands of products.
• Actions: status changes via the state machine (/api/_action/order/{id}/state/…), generating documents, sending emails, triggering indexing.
• Versioning and metadata: /api/_info/ returns the version, available entities, and the OpenAPI schema; the Swagger UI at /api/_info/swagger.html documents all endpoints.

In a typical ERP integration, the Admin API handles these data flows:

• Products and prices: The ERP is the system of record; Shopware receives master data, variants, and prices via the Sync API.
• Stock: Inventory levels are updated at short intervals or event-driven, so availability in the store is accurate.
• Orders: The ERP fetches new orders using a search with the criterion “order status open and not yet exported” and then flags them, for example with a custom field.
• Status and tracking numbers: Shipping and payment statuses are written back via state machine actions, and tracking numbers are attached to the delivery.

Instead of polling on a schedule, you can let Shopware notify you: webhooks report new orders or changed products, and the integration then loads only what has changed. Our overview of ERP and CRM integrations shows which systems can be connected this way, and our guide to Xentral and Shopware 6 gives a concrete example.

• Use the Sync API for bulk data: Individual calls per product are too slow for large catalogs; batch write operations in packages of a few hundred records.
• Transfer only changes: With updatedAt filters or webhooks, you transfer only deltas instead of the entire dataset.
• Work idempotently: Use fixed IDs (UUIDs) from your system of record so repeated calls don’t create duplicates.
• Handle errors: The Sync API reports errors per record; log failed entries and retry them selectively.
• Mind the indexing: After large imports, indexers run through the message queue; the worker must be active, otherwise data shows up in the store with a delay.
• Permissions and secrets: a separate integration per system, a minimal role, keys in a secret store, regular rotation.

• 401 Unauthorized: Token expired or wrong credentials. Renew the token and check the integration.
• 403 Forbidden: The integration’s role lacks permission for this entity or operation.
• 400 on write operations: Required fields are missing or data types don’t match; the error message names the field and path.
• Data doesn’t appear in the store: Indexer or cache. Check the message queue worker and clear the cache.
• Slow imports: Individual calls instead of the Sync API, or packages that are too large; with the header indexing-behavior: use-queue-indexing, you can move indexing to the queue.

The Admin API is the backbone of every Shopware integration. Once you understand its logic, with OAuth 2.0, search with criteria, the Sync API, and the state machine, you can reliably connect ERP, PIM, and CRM. For custom integrations and plugins that extend the Admin API with your own endpoints, we support you with Shopware plugin development.