Reference · built on requestConnectorCommerce & orders

Shopware

Orders, deliveries, payment transactions, customers, and app webhooks from Shopware 6 through the Admin API.

Request accessPricing ↗

About

Shopware is an open-source commerce platform, self-hosted or cloud. Every order carries three state machines, order, order_delivery, and order_transaction, so status, shipping, and payment move independently along defined transitions. The Admin API at /api offers create, read, update, and delete on every entity plus search criteria, and apps receive events such as checkout.order.placed as signed webhooks declared in a manifest.

Through Fibric, an operator reads orders and their line items, then proposes a state transition: ship a delivery, mark a payment refunded, or cancel an order. You approve. The connector posts the transition once and leaves a record: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Shopware and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders through POST /api/search/order with criteria for filtering, sorting, and aggregation, and line items through GET /api/order/{id}/line-items
  • Order state, delivery state, and payment state from the order, order_delivery, and order_transaction state machines
  • checkout.order.placed, order.written, and state_enter.order_delivery.state.shipped webhooks from an app manifest, signed with shopware-shop-signature
  • state_enter.order_transaction.state.paid and the other state_enter and state_leave events for order, delivery, and transaction states
  • Customers and products through the same entity endpoints, with product.written and customer.written events carrying the changed entity's primary key

Proposed actions

  • Target capability: propose an order transition (process, complete, cancel, reopen) through POST /api/_action/order/{orderId}/state/{transition}
  • Target capability: propose a delivery transition (ship, ship_partially, retour, retour_partially) through POST /api/_action/order_delivery/{id}/state/{transition}
  • Target capability: propose a payment transition (paid, refund, refund_partially, remind, cancel) through POST /api/_action/order_transaction/{id}/state/{transition}
  • Target capability: propose a refund on a successful transaction through the Admin API refund endpoint, where the payment handler supports refunds

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Ship when the label exists

    When your carrier system issues tracking, the operator proposes the ship or ship_partially transition on the order_delivery. You approve. The state_enter.order_delivery.state.shipped event confirms it.

    With Tracking Sync

  • Cancel inside the window

    A customer asks to cancel. The operator checks the delivery state and payment state and proposes the cancel transition on the order and on its transaction, or routes it to a person if it already shipped.

    With Cancellation Window

  • Refund by policy

    A refund request arrives. The operator reads the order_transaction, confirms it is paid, and proposes refund or refund_partially with the amount and reason for your approval.

    With Refund Policy

  • Hold suspect orders

    checkout.order.placed fires. The operator fetches the order, compares totals, addresses, and payment state against your rules, and flags orders to hold before the delivery is processed.

    With Order Risk

Requirements

  • A Shopware 6 instance with the Admin API reachable from Fibric
  • An integration created under Settings > System > Integrations, with the roles or Administrator toggle that grant order, order_delivery, and order_transaction access
  • For webhooks, an installed app whose manifest.xml declares the webhooks and holds order:read, customer:read, or product:read permissions as each event requires
  • Token refresh: access tokens expire after about 600 seconds, so the connector re-requests or refreshes before each batch
Authentication
An OAuth 2.0 access token from POST /api/oauth/token using the client_credentials grant with an integration's access key and secret, sent as Authorization: Bearer.

Limits

  • Order returns are managed only in the Administration; the documented return endpoints go through the proxy API as the logged-in user.
  • Refunds through the Admin API depend on the payment extension: it must implement RefundPaymentHandlerInterface and record its own captures and refunds.
  • entity.written webhooks carry only the primary key; the connector fetches the full entity afterwards.
  • The oauth route is rate limited by default at 10 per 10 seconds, 15 per 30 seconds, and 20 per 60 seconds, then returns 429.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Shopware ↗

Questions and answers

Which grant should an integration use?
client_credentials. Create an integration under Settings > System > Integrations to get an access key and secret, then POST them to /api/oauth/token. The password grant with client_id administration is documented only as a local development shortcut.
How are order states changed through the API?
By posting a transition to the state machine: POST /api/_action/order/{orderId}/state/{transition} for the order, and matching routes for order_delivery and order_transaction. Order transitions are cancel, complete, reopen, and process. A cancelled order must be reopened before it can progress.
How are app webhooks secured?
Each POST carries a shopware-shop-signature header holding a SHA256 HMAC of the request body, signed with the app secret from registration. The body includes source.shopId and source.eventId, which stays the same on retries, so a receiver can drop duplicates.
Ask about Shopware

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Shopware through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy