---
title: 'Administration: Architecture and Core Technologies | Shopware Community Hub'
description: >-
Learn which technologies power the Shopware administration. Understand its
purpose, architecture, and how it differs from the Shopware storefront.
canonical_url: >-
https://hub.shopware.com/learn/unit/administration-architecture-and-core-technologies
---
# Administration: Architecture and Core Technologies
- Learn the role of the Shopware administration as the merchant-facing extension area.
- Identify the core technologies behind administration development, including Vue 3, Vite, Pinia, Twig.js, Vue I18n, and Meteor components.
- Understand how the administration communicates with the backend through the Admin API and `repositoryFactory`.
- Distinguish storefront JavaScript from administration JavaScript.
# Administration: Architecture and Core Technologies
As you already know, the storefront is the customer-facing part of Shopware. You have already learned how to customize it with Twig, SCSS, Bootstrap, and JavaScript.
But what if your project requires internal customization, for example, a custom overview, dashboard, or workflow for merchants? That is where administration development comes in.
## What is the Shopware Administration?
The Shopware administration is the central interface for merchants and shop managers. It is where shop data and configuration are managed, from products and categories to customers, orders, and payment or shipping methods. In the administration, you can:
- Create and manage products, categories, and customers.
- Configure delivery and payment methods.
- Manage discounts, promotions, and vouchers.
- Build and organize content pages using the Shopping Experience (CMS).
- Set up and manage sales channels.
A single Shopware instance can host **multiple sales channels**, which means you can run different storefronts (e.g., for different brands and regions) from one administration.
For developers, the administration is not only a management tool. It is also an extension point for modules, existing views, and custom tools that support merchant workflows.
## Why Does It Matter for Developers?
The administration is the right place for tools, dashboards, and workflows that help merchants manage the shop. Typical use cases include:
- **Meeting merchant requirements:**
- Add custom navigation entries (e.g., "Premium Products").
- Create dashboards or reports (e.g., "Top 10 Products").
- Implement CMS elements that contain business logic and appear in the storefront.
- Integrate external systems (e.g., an ERP system) via plugin logic and provide a configuration or dashboard for it within the administration.
- **Improving merchant workflows:**
- Build features that simplify repetitive tasks (e.g., bulk editing or quick exports).
- Add interactive views or filters for better data management.
- Reduce manual steps through automation or smarter UI components.
- **Connecting storefront and administration:**
- Configure storefront features via the administration (e.g., custom CMS elements).
- Keep business logic centralized in the backend and ensure consistent behavior across the storefront and administration; configured in the administration, rendered in the storefront.
## Technologies Used in the Administration
The Shopware administration is a merchant-facing single-page application (SPA). It provides the user interface for managing the shop and communicates with the Shopware backend through APIs.
### Core Technologies
If you have worked with the Shopware administration before, you will notice that Shopware 6.7 introduced several breaking changes and major architecture updates.
This learning unit explains the current architecture so you can work efficiently with Shopware 6.7 and later versions.
If you want to explore the changes in more detail, see the [Shopware 6.7 Changelog](https://developer.shopware.com/release-notes/6.7/6.7.0.0.html).
Technically, the administration is built with Vue 3 and a modern JavaScript toolchain.
This toolchain is a combination of technologies that work together to build the administration – from rendering the interface to managing state to compiling assets.
In addition to this toolchain, Shopware provides the `Shopware` object as its extension framework. It offers APIs to register modules, components, snippets, and services without modifying the core.
The following overview introduces the toolchain used in the administration and explains the purpose of each technology.
#### Vue.js (Version 3)
Vue is the JavaScript framework used to build reactive and modular administration interfaces. It enables reusable components, state-driven rendering, and dynamic views.
Vue 3 introduces the Composition API and brings performance improvements, such as a smaller bundle size and a faster virtual DOM, compared to Vue 2. For more details about Vue 3, see the [Vue FAQ](https://vuejs.org/about/faq#what-s-the-difference-between-vue-2-and-vue-3).
#### The Vue Router
The **Vue Router** is the official client-side routing library for Vue.js. It handles navigation within the administration by mapping routes to specific components or pages. Each module or page in the administration (e.g., Orders, Customers, Products) is registered as a route and rendered dynamically when selected.
For more information about the Vue Router, see the [Vue Router Guide](https://router.vuejs.org/guide/) and the [Vue Routing Overview](https://vuejs.org/guide/scaling-up/routing.html).
#### The Pinia State Management Library
Pinia is the official state management library for Vue 3 used in the administration. It helps manage shared state across components, for example, selected entities, filters, or user preferences.
Pinia is used to share and synchronize data between multiple components, for example, when different views rely on the same product or customer data.
Pinia provides a simple API, is fully TypeScript-ready, and works seamlessly with Vue 3. It enables developers to define [modular](https://en.wikipedia.org/wiki/Modular_programming), [reactive](https://vuejs.org/guide/essentials/reactivity-fundamentals.html#reactivity-fundamentals), and easy-to-test stores that simplify data handling within the administration.
- **Simple API**: Less boilerplate code compared to Vuex.
- **TypeScript support**: Pinia is fully TypeScript-ready and provides type definitions for all state properties; no extra setup is required.
- **Official Vue Replacement**: Pinia is the recommended successor to Vuex.
For more details, visit the [official Pinia documentation](https://pinia.vuejs.org/introduction.html#Why-should-I-use-Pinia-).
#### The Vite Build System
Vite is the frontend build tool used to compile and bundle the administration.
It compiles, bundles, and serves JavaScript, CSS, and other assets during development and production.
Advantages include:
- **Faster Builds**: Thanks to native ES module support and on-demand compilation.
- **Instant Updates**: With Hot Module Replacement (HMR), for near-instant feedback during development.
- **Simplified configuration**: Vite requires less setup and provides sensible defaults.
- **Modern architecture**: Built with esbuild and Rollup under the hood for optimized production builds.
To learn more about Vite, visit the [official Vite documentation](https://vite.dev/guide/why.html).
#### The SCSS Styling Language
The Shopware administration uses SCSS for styling and theming its user interface. While the storefront uses Bootstrap for styling, the administration takes a different approach.
It uses the [Meteor Component Library](https://github.com/shopware/meteor), which provides theme-consistent Vue components such as `mt-button` and `mt-card`.
Each module in the administration has its own components with their own styling and business logic like product listings and detail pages.
This ensures visual consistency, reduces custom styling, and allows module-specific adaptations when necessary.
#### The Twig.js JavaScript Templating Engine
Twig.js is a JavaScript templating engine used within the administration, but only in a very limited form. Shopware enables only the `block` feature of Twig.js to structure component templates. Other Twig features, such as conditions, loops, or filters, are disabled.
All dynamic renderings, including conditions, loops, and data-binding, are handled entirely by Vue.js, not by Twig.js.
Twig.js is therefore used only as a lightweight layout helper to define block placeholders inside Vue component templates. It does not process data from JavaScript and should not be confused with the full Twig engine used in the storefront.
Twig.js is different from PHP-Twig.
Twig.js runs client-side inside the administration SPA, is processed by JavaScript, not PHP, and supports only block inheritance.
For more information, see the [Shopware administration concept](https://developer.shopware.com/docs/concepts/framework/architecture/administration-concept.html).
#### The Vue I18n Plugin
Vue I18n is the official internationalization (i18n) plugin for Vue.js. It allows developers to translate static and dynamic text and adapt the user interface for different languages.
In the Shopware administration, Vue I18n works together with the Shopware's [snippet system](https://developer.shopware.com/docs/guides/plugins/plugins/administration/templates-styling/adding-snippets.html#overview), which stores and manages all translatable texts (e.g., button labels, tooltips, and messages).
Developers can reference snippets directly in their components and Twig.js templates to ensure that the UI is automatically localized based on the selected language. This integration makes it easy to build multi-language-ready modules and components.
Administration snippets are loaded from JSON files during the administration build. They are not edited through the snippet editor in the Administration UI. That editor is relevant for storefront snippets, while administration snippets are part of your extension code.
For example, you can access a snippet in your component using the `$t()` function:
```vue
this.$t('my-module.label.saveButton');
```
The snippet `my-module.label.saveButton` will be translated automatically based on the selected language.
The administration uses the **Vue I18n v10** internationalization library. In this version, the classic `tc` function has been replaced by the `t` function.
For compatibility reasons, Shopware provides an internal fallback that maps `tc` to `t` to avoid breaking extensions.
#### The Admin API
The Admin API is a REST API that connects the Shopware administration (frontend) with the Shopware core (backend). It is responsible for fetching, creating, updating, and deleting data such as products, customers, orders, or categories.
By using the Admin API, the administration communicates with the backend via HTTP requests and JSON responses, ensuring a clean separation between the frontend layer (Vue.js) and the backend layer (PHP, business logic). This architecture makes the system more modular, secure, and extensible.
There are two common ways to work with the Admin API, depending on where your code runs.
When you build administration UI extensions, you usually do not write raw Admin API requests by hand. Instead, you use the repository layer through `repositoryFactory`. The repository handles the Admin API communication for you and gives your Vue components a consistent way to search, create, update, and delete entities.
When you build external integrations, apps, automation, or system-to-system processes, direct Admin API usage is the normal approach. For example, an ERP integration may call the Admin API directly to synchronize products, orders, or customers.
The Admin API itself provides a wide range of [core endpoints](https://shopware.stoplight.io/docs/admin-api/8d53c59b2e6bc-shopware-admin-api). Developers can also define custom endpoints via the **manifest.xml in Apps** or by registering **custom controllers in Plugins**. Authentication and authorization are handled via OAuth 2.0.
In practical administration modules, you usually start from the entity you need, create a repository with `repositoryFactory`, and inspect existing core modules to see which entity, repository, or service they use. Later practical labs in this learning path apply this pattern hands-on.
Always use the **repositoryFactory** service to interact with entities such as products, orders, or customers. This approach ensures consistent data access and better maintainability.
For demonstration purposes only, here is what a manual request looks when using `curl`:
```bash
curl --request POST \
--url http://localhost:8000/api/search/product \
--header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
--header 'Content-Type: application/json' \
--data '{
"limit": 10,
}'
```
### Shopware-Specific Tools and Libraries
In addition to the modern JavaScript toolchain, the Shopware administration also provides its own extension framework and a set of built-in tools that make development easier and more consistent.
These tools allow developers to extend the administration **without modifying its core**, ensuring a clean, modular, and updatable structure.
In the following section, you will see an overview of the most important Shopware-specific tools you will work with.
#### The Shopware Object
The Shopware object is the **central entry point** for extending the administration. It provides APIs to register modules, components, services, mixins, and more. This allows you to integrate new functionality such as custom modules or configuration pages without changing the core.
You will learn more about the Shopware object and its structure **later** in this [learning unit](/learn/administration-the-shopware-object).
#### Shopware Services and Utilities
The Shopware administration provides several built-in services and utilities that simplify common development tasks such as data fetching, state management, notifications, and API communication.
These are accessible via the Shopware object and can be used directly inside your modules and Vue components.
Some commonly used services include:
- The **[repositoryFactory](https://developer.shopware.com/docs/guides/plugins/plugins/administration/data-handling-processing/using-data-handling.html#the-repository-service)** for creating repositories to read and write data via the Admin API.
- The **[Access Control List (ACL)](https://developer.shopware.com/docs/concepts/framework/architecture/administration-concept.html#acl-in-the-administration)** for managing user permissions.
- The **[context](https://developer.shopware.com/resources/admin-extension-sdk/api-reference/context.html#context)** for accessing the current API context (e.g., language, currency, locale, etc.).
- The **loginService** (internally provided) for managing authentication and access tokens. It is available via `Shopware.Service('loginService')` but not officially documented.
This approach ensures a consistent, centralized, and maintainable way to work with shared functionality across the administration.
If you want to dive deeper into which services Shopware provides, check the [official GitHub repository](https://github.com/shopware/shopware/tree/trunk/src/Administration/Resources/app/administration/src/core/service)
#### Shopware UI Components
The Shopware administration includes a rich set of pre-built UI components that form the foundation of its user interface. These components are designed to ensure visual consistency, usability, and accessibility across all modules.
Developers can reuse these components to build new views in a standardized way. Common examples include:
- The `mt-button` for consistent button style and behavior.
- The `mt-card` for structured content containers.
- The `mt-modal` for modal dialogs and confirmations.
For Shopware 6.7 and later, use the Meteor `mt-*` components for new administration code. Older `sw-*` components (e.g., `sw-button`, `sw-card`, `sw-modal`) still exist in legacy examples and core areas for backward compatibility, but they should not be the default choice for new extensions.
Meteor components follow Vue's standard patterns, including props, events, slots, and internal state. For example, a save action should use `mt-button` instead of a custom-styled button:
```vue
{{ $t('my-module.general.save') }}
```
This keeps the look and behavior aligned with the rest of the administration.
For more information about the available components, visit the [official GitHub repository](https://github.com/shopware/meteor/tree/main/packages/component-library/src/components).
### Backend Communication
The Shopware administration communicates with the Shopware Core (backend) via the [Admin API](https://shopware.stoplight.io/docs/admin-api/8d53c59b2e6bc-shopware-admin-api). This API acts as a bridge between the frontend (Vue.js SPA) and the backend (PHP, business logic), ensuring a clear separation between the two layers.
All data displayed or modified in the administration, such as products, orders, or customers, is fetched or updated through Admin API requests. The API uses RESTful endpoints and exchanges data in JSON format.
#### Authentication and Context
The Admin API uses **OAuth 2.0** for authentication. When a user logs into the administration, an **access token** is generated and stored. All subsequent API calls include this token in the request header to ensure secure communication.
Each request also operates within a **Shopware context**, which includes details such as the current language, currency, locale, and user permissions. This context can be accessed within the administration via the [context](https://developer.shopware.com/resources/admin-extension-sdk/api-reference/context.html#context) service, ensuring all API interactions are localized and role-aware.
#### Data Access With Repositories
To simplify data handling, Shopware provides the [repositoryFactory](https://developer.shopware.com/docs/guides/plugins/plugins/administration/data-handling-processing/using-data-handling.html#the-repository-service). This service allows developers to create repositories for specific entities (e.g., products, orders, customers, etc.) and perform CRUD operations (create, read, update, and delete) directly from Vue components.
**Example:**
```vue
const productRepository = Shopware.Service('repositoryFactory').create('product');
productRepository.search(criteria, context).then((response) => {
// do something with the response
});
```
This pattern ensures that all data access is consistent, typed, and context-aware, while maintaining a clean separation between the frontend and the backend.
---
The following screenshot summarizes the toolchain and structure of the Shopware administration.
## Storefront JavaScript vs. Administration JavaScript
Although both the storefront and the administration use JavaScript, they solve different problems. The storefront enhances server-rendered customer pages. The administration is a client-rendered merchant application. The following table summarizes the key differences.
| Aspect | Storefront | Administration |
|-------------------------|-------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|
| **Purpose** | Controls the **customer-facing** interface (what shoppers see). | Powers the **merchant-facing** interface (where shop managers work). |
| **Framework** | Vanilla JS with Shopware's **Storefront Plugin System** (based on the Plugin base class). | **Vue 3 SPA** with **modules**, **components**, and the **Shopware object**. |
| **Rendering** | Rendered **server-side** (PHP/Twig) and enhanced **client-side** with JavaScript. | Rendered **client-side** with **Vue.js**. |
| **Extension Model** | Extend templates with Twig and add behavior with storefront JavaScript plugins. | Extend the merchant UI with **Shopware modules**, **Vue components**, and **Twig.js blocks**. |
| **Styling** | Uses SCSS together with Bootstrap and storefront theme styling. | Uses SCSS together with the Meteor Component Library and administration component styles. |
| **Dependency Handling** | Bundled via **Webpack**. | Bundled via **Vite**. |
| **State Management** | Local or via DOM (Document Object Model). | **Global state** via **Pinia**. |
| **API Communication** | Typically via **Store API**. | Via **Admin API** |
| **Access Control** | Public, exposed to customers. | Restricted, OAuth 2.0 authentication required. |
**Key Takeaways:**
- The storefront focuses on UX and presentation for customers, while the administration focuses on tools and workflows for merchants.
- Storefront JavaScript extends server-rendered pages, while administration JavaScript builds a client-rendered SPA.
- Both environments follow modular patterns, but use different extension systems.
- Use the Store API for the storefront, and the Admin API in the administration.
## Summary
In this learning unit, you learned the fundamentals of the Shopware administration and how it differs from the storefront.
By now, you learned:
- The administration is the merchant-facing UI, not the customer-facing storefront.
- It is built as a Vue 3 Single Page Application (SPA), so routing and state work differently than in the storefront.
- It communicates with the backend via the Admin API, while business logic stays in the backend.
- You extend the administration through the `Shopware` object (modules, components, snippets, services).
- The toolchain is modern (Vite, Pinia, SCSS, Vue I18n) and supports fast development.
- Twig.js in the administration is not PHP-Twig. It is mainly used for block structure, while Vue handles rendering logic.
- For UI building blocks, prefer Meteor (`mt-*`) components over legacy `sw-*` components.
With this foundation, you are ready to start building your own administration extensions.