Spryker Documentation

API Platform

Thu, 29 Jan 2026 11:34:53 +0000

Spryker’s API Platform integration provides schema-based API resource generation with automatic OpenAPI documentation. This allows you to define your API resources using YAML schemas and automatically generate fully functional API endpoints with validation, pagination, and serialization.

This document describes the API Platform architecture and how it integrates with Spryker.

What is API Platform

API Platform is a framework for building modern APIs based on web standards and best practices. In Spryker, it complements the existing Glue API infrastructure by providing:

Schema-based resource generation: Define resources in YAML, generate PHP classes automatically
Automatic OpenAPI documentation: Interactive API documentation generated from schemas
Built-in validation: Symfony Validator integration with operation-specific rules
Pagination support: Standardized pagination with configurable defaults
State management: Separate providers (read) and processors (write) for clean architecture

Read more about the API Platform project at api-platform.com.

CodeBucket support

Currently, the API-Platform integration does not support code buckets. When defining resources, use only the Core and Project layers.

Code bucket support is planned for future releases.

Architecture overview

Resource generation workflow

>Schema Files (YAML)
    ↓
Schema Discovery & Validation
    ↓
Multi-layer Schema Merging (Core → Feature → Project → [Code Buckets])
    ↓
Resource Class Generation
    ↓
API Platform Resource (with attributes)
    ↓
API Endpoints

Core components

1. Schema files

Resources are defined in YAML files located in module directories:

>src/Spryker/{Module}/resources/api/{api-type}/{resource-name}.resources.yml
src/Spryker/{Module}/resources/api/{api-type}/{resource-name}.validation.yml

Example resource schema src/Spryker/{Module}/resources/api/{api-type}/{resource-name}.resources.yml:

resource:
  name: Customers
  shortName: Customer
  description: "Customer resource for backend API"

  provider: "Pyz\\Glue\\Customer\\Api\\Backend\\Provider\\CustomerBackendProvider"
  processor: "Pyz\\Glue\\Customer\\Api\\Backend\\Processor\\CustomerBackendProcessor"

  paginationEnabled: true

  operations:
    - type: Post
    - type: Get
    - type: GetCollection
    - type: Patch
    - type: Delete

  properties:
    email:
      type: string
      description: "Customer email address"
    customerReference:
      type: string
      identifier: true
      writable: false

Example validation schema src/Spryker/{Module}/resources/api/{api-type}/{resource-name}.validation.yml:

post:
  name:
    - NotBlank:
        message: First name is required
    - Length:
        min: 2
        max: 64
        minMessage: First name must be at least 2 characters
        maxMessage: First name cannot exceed 64 characters

patch:
  name:
    - Optional:
        constraints:
          - Length:
              min: 2
              max: 64
              minMessage: First name must be at least 2 characters
              maxMessage: First name cannot exceed 64 characters

2. Generated resources

The generator creates PHP classes with API Platform attributes:

src/Generated/Api/Backend/CustomersBackendResource.php

<?php

namespace Generated\Api\Backend;

use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\ApiProperty;
use Symfony\Component\Validator\Constraints as Assert;

#[ApiResource(
    operations: [new Post(), new Get(), new GetCollection(), new Patch(), new Delete()],
    shortName: 'Customer',
    provider: CustomerBackendProvider::class,
    processor: CustomerBackendProcessor::class
)]
final class CustomersBackendResource
{
    #[ApiProperty(identifier: true, writable: false)]
    public ?string $customerReference = null;

    #[ApiProperty]
    #[Assert\NotBlank(groups: ['customers:create'])]
    #[Assert\Email(groups: ['customers:create'])]
    public ?string $email = null;

    // Getters, setters, toArray(), fromArray()...
}

3. State providers and processors

Detailed information about the API-Platform Provider and Resources can be found on the public docs:

Provider (read operations):

class CustomerBackendProvider implements ProviderInterface
{
    public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null
    {
        // Fetch and return data from your business layer
        return $customerResource;
    }
}

Processor (write operations):

class CustomerBackendProcessor implements ProcessorInterface
{
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
    {
        // Persist changes through your business layer
        return $updatedResource;
    }
}

API types

Any of the existing APIs can be extended using API Platform.

Spryker supports multiple API types for different use cases:

Glue API

This API is configured to serve the JSON:API format by default, which can be configured per project. Projects migrating their APIs can provide new APIs as well as supporting the existing ones while migrating.

API Type: storefront
Application: Glue
Base URL: http://glue.eu.spryker.local/ - Configurable per project
Use cases: Customer-facing APIs, mobile apps, PWAs

GlueStorefront API

Thie API is configured to serve the JSON+LD format by default, which can be configured per project.

API Type: storefront
Application: Glue
Base URL: http://glue-storefront.eu.spryker.local/ - Configurable per project
Use cases: Customer-facing APIs, mobile apps, PWAs

GlueBackend API

API Type: backend
Application: Zed
Base URL: http://glue-backend.eu.spryker.local/
Use cases: Admin panels, internal tools, ERP integrations

Merchant Portal API

API Type: merchant-portal
Application: MerchantPortal
Base URL: http://mp.glue.eu.spryker.local/
Use cases: Marketplace merchant interfaces
Example: /products

Multi-layer schema merging

One of the key features is support for multi-layer schema definitions that automatically merge:

Core layer (vendor/spryker):

resource:
  name: Customers
  properties:
    email:
      type: string

Feature layer (src/SprykerFeature):

resource:
  name: Customers
  properties:
    loyaltyPoints:
      type: integer

Project layer (src/Pyz):

resource:
  name: Customers
  properties:
    email:
      required: true  # Override core
    customField:
      type: string    # Project-specific

Result: A single merged resource with all properties, project code-bucket layer taking precedence.

Integration with Spryker architecture

Dependency Injection

API Platform fully integrates with Symfony Dependency Injection:

// config/Zed/ApplicationServices.php
$services->load('Pyz\\Zed\\', '../../../src/Pyz/Zed/');

Providers and Processors are automatically discovered and can use constructor injection:

class CustomerBackofficeProvider implements ProviderInterface
{
    public function __construct(
        private CustomerFacadeInterface $customerFacade,
        private CustomerRepositoryInterface $customerRepository,
    ) {}
}

Facade integration

Resources can leverage existing Spryker facades:

class CustomerBackendProcessor implements ProcessorInterface
{
    public function __construct(
        private CustomerFacadeInterface $customerFacade,
    ) {}

    public function process(mixed $data, Operation $operation, ...): mixed
    {
        $customerTransfer = $this->mapToTransfer($data);
        $response = $this->customerFacade->createCustomer($customerTransfer);
        return $this->mapToResource($response->getCustomerTransfer());
    }
}

Resource generation

Console commands

All the following commands can be used with a specific GLUE_APPLICATION by prefixing them with GLUE_APPLICATION=GLUE_BACKEND environment variable. For example: docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND glue api:debug --list

# Generate resource classes for all configured API types at once. Usually used during deployment/installation.
docker/sdk cli glue api:generate

# Generate API type specific resource classes. Usually used during development.
docker/sdk cli glue api:generate backend

# Validate schemas only to see if there is any issue in the definitions
docker/sdk cli glue api:generate --validate-only

Debug commands

# List all resources to see which ones are defined in the schema files.
docker/sdk cli glue  api:debug --list

# Inspect specific resource and print details about properties and operations
docker/sdk cli glue  api:debug customers --api-type=backend

# Show merged schema
docker/sdk cli glue  api:debug customers --api-type=backend --show-merged

# Show contributing files for a resource
docker/sdk cli glue  api:debug customers --api-type=backend --show-sources

Features

Automatic OpenAPI documentation

API Platform generates interactive OpenAPI documentation:

Swagger UI at the root URL / for example http://glue-backend.eu.spryker.local/

You can disable this interface in production environments by configuring the settings in your api_platform.php configuration file. For details, see Disable Swagger UI.

Built-in validation

Validation rules from *.validation.yml files are converted to Symfony Validator constraints:

post:
  email:
    - NotBlank
    - Email

Becomes:

#[Assert\NotBlank(groups: ['customers:create'])]
#[Assert\Email(groups: ['customers:create'])]
public ?string $email = null;

Pagination support

Standardized pagination with query parameters:

>GET /customers?page=2&itemsPerPage=20

Provider returns PaginatorInterface:

return new TraversablePaginator(
    new \ArrayObject($results),
    $currentPage,
    $itemsPerPage,
    $totalItems
);

Operation-specific behavior

Define different validation and behavior per operation:

operations:
  - type: Post            # Create
  - type: Get             # Read one
  - type: GetCollection   # Read many
  - type: Patch           # Update
  - type: Delete          # Delete

Each operation can have specific validation rules and security settings.

Performance

Cache warming

Pre-generate resources during deployment:

docker/sdk cli glue  api:generate

docker/sdk cli glue  cache:warmup

Property-level access control

properties:
  password:
    writable: true   # Can be written
    readable: false  # Not in responses

Comparison with Glue API

Feature	API Platform	Glue API
Definition	Schema-based (YAML)	Code-based (PHP)
Documentation	Auto-generated OpenAPI	Manual
Validation	Declarative	Programmatic
Standards	JSON-LD, Hydra	JSON API
Learning curve	Lower	Higher
Flexibility	High	Very high
Use cases	Standard CRUD	Complex business logic

Both can coexist in the same application. For further migration guidance, see How to migrate to API Platform.

For detailed implementation guides:

How to integrate API Platform - Setup and configuration
How to migrate to API Platform - Migrate endpoints from Glue API
API Platform Configuration - Configure API Platform settings
API Platform Enablement - Creating your first resource
Resource Schemas - Resource Schemas
Validation Schemas - Validation Schemas
CodeBucket Support - Region-specific resources
Troubleshooting API Platform - Common issues

Next steps

API Platform Configuration

Thu, 29 Jan 2026 11:19:00 +0000

Spryker uses API Platform’s configuration options with Spryker-specific adaptations for PHP-based configuration and environment control.

Configuration file locations

Configuration files are located in application-specific directories:

GlueBackend: config/GlueBackend/packages/api_platform.php
GlueStorefront: config/GlueStorefront/packages/api_platform.php
Glue: config/Glue/packages/api_platform.php

Spryker-specific differences

PHP configuration instead of YAML

Spryker uses PHP configuration with Symfony’s type-safe configuration objects instead of YAML files:

use Symfony\Config\ApiPlatformConfig;

return static function (ApiPlatformConfig $apiPlatform, string $env): void {
    // Configuration here
};

Environment variable for conditional settings

The configuration function receives an $env parameter for environment-specific behavior:

return static function (ApiPlatformConfig $apiPlatform, string $env): void {
    // Enable developer tools only in development
    if ($env === 'dockerdev') {
        $apiPlatform->enableSwagger(true);
        $apiPlatform->enableSwaggerUi(true);
        $apiPlatform->enableReDoc(true);
        $apiPlatform->enableDocs(true);
    }
};

Common environment values: prod, dev, dockerdev, test

Configuration examples

Disable SwaggerUI in production

Spryker shows the SwaggerUI only in development environments by default. This can be configured with:

if ($env === 'dockerdev') {
        $apiPlatform->enableSwagger(true);
        $apiPlatform->enableSwaggerUi(true);
        $apiPlatform->enableReDoc(true);
        $apiPlatform->enableDocs(true);
    }

Disable Doctrine integration

Spryker does not use Doctrine with API Platform:

$apiPlatform->doctrine()->enabled(false);
$apiPlatform->doctrineMongodbOdm()->enabled(false);

Configure resource mapping paths

Specify where generated API resources are located:

$apiPlatform->mapping()->paths([
    '%kernel.project_dir%/src/Generated/Api/Backend'
]);

Set pagination defaults

$apiPlatform->defaults()->paginationItemsPerPage(10);

$apiPlatform->collection()
    ->pagination()
        ->pageParameterName('page')
        ->itemsPerPageParameterName('itemsPerPage');

Configure supported formats

$apiPlatform->formats('jsonapi', ['mime_types' => ['application/vnd.api+json']]);
$apiPlatform->formats('jsonld', ['mime_types' => ['application/ld+json']]);
$apiPlatform->formats('xml', ['mime_types' => ['application/xml']]);

Complete configuration reference

For all available configuration options and their details, refer to the API Platform Symfony Configuration documentation.

The PHP method names in ApiPlatformConfig correspond directly to the YAML keys in the official documentation.

How to integrate API Platform

Thu, 29 Jan 2026 10:05:27 +0000

This document describes how to integrate API Platform into your Spryker application to enable schema-based API resource generation. ## Prerequisites Before integrating API Platform, ensure you have: - Upgraded to Symfony Dependency Injection as described in [How to upgrade to Symfony Dependency Injection](/docs/dg/dev/upgrade-and-migrate/upgrade-to-symfony-dependency-injection.html) - PHP 8.1 or higher - Symfony 6.4 or higher components ## 1. Install the required modules To integrate API Platform, install the following modules: ```bash composer require spryker/api-platform:"^0.5.0" --update-with-dependencies ``` {% info_block infoBox "Module placeholder" %} The exact module versions will be provided in the final documentation. The above serves as a placeholder for the module list. {% endinfo_block %} ## 2. Register bundles Register the required bundles in your application's bundle configuration files for each application layer where you want to enable API Platform. ### For Glue application `config/Glue/bundles.php` ```php ['all' => true], TwigBundle::class => ['all' => true], ApiPlatformBundle::class => ['all' => true], SprykerApiPlatformBundle::class => ['all' => true], ]; ``` ### For GlueStorefront application `config/GlueStorefront/bundles.php` ```php ['all' => true], ApiPlatformBundle::class => ['all' => true], SprykerApiPlatformBundle::class => ['all' => true], TwigBundle::class => ['all' => true], ]; ``` ### For GlueBackend application `config/GlueBackend/bundles.php` ```php ['all' => true], ApiPlatformBundle::class => ['all' => true], SprykerApiPlatformBundle::class => ['all' => true], TwigBundle::class => ['all' => true], ]; ``` ## 3. Configure API Platform Create configuration files for the API Platform in each application layer where you want to enable the API-Platform. ### Configure for Glue `config/Glue/packages/spryker_api_platform.php` ```php apiTypes(['storefront']); }; ``` ### Configure for GlueStorefront `config/GlueStorefront/packages/spryker_api_platform.php` ```php apiTypes(['storefront']); }; ``` ### Configure for GlueBackend `config/GlueBackend/packages/spryker_api_platform.php` ```php apiTypes(['backend']); }; ``` ## 4. Update Router Configuration Update the router dependency provider for each application where you want to enable API Platform routes. ### For Glue application `src/Pyz/Glue/Router/RouterDependencyProvider.php` ```php */ protected function getRouterPlugins(): array { return [ new GlueRouterPlugin(), // Existing Glue API router new SymfonyFrameworkRouterPlugin(), // Add this for API Platform routes ]; } } ``` {% info_block infoBox "Router order matters" %} The order of router plugins matters. The `SymfonyFrameworkRouterPlugin` must be added after existing router plugins to ensure the correct routing priority. The `GlueRouterPlugin` should remain the first in the list to handle existing and not yet migrated Glue API endpoints. When migrating existing Glue API endpoints to API Platform, you need to remove endpoints from the `GlueRouterPlugin` so that the `SymfonyFrameworkRouterPlugin` is used to resolve the route. To remove routes from the `GlueRouterPlugin` update the corresponding `GlueApplicationDependencyProvider`, `GlueBackendApiApplicationDependencyProvider`, or `GlueStorefrontApiApplicationDependencyProvider` and remove the resource route plugin for the route you currently migrate. {% endinfo_block %} ## 5. Generate API resources After configuration, generate your API resources from schema files: ```bash # Generate resources for all configured API types in Glue docker/sdk cli glue api:generate # Generate resources for all configured API types in GlueStorefront docker/sdk cli GLUE_APPLICATION=GLUE_STOREFRONT glue api:generate # Generate resources for all configured API types in GlueBackend docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND glue api:generate # Generate resources for a specific API type in Glue (others can follow the env var examples above) docker/sdk cli glue api:generate storefront docker/sdk cli glue api:generate backend # Dry run (see what would be generated) docker/sdk cli glue api:generate --dry-run # Validate schemas only docker/sdk cli glue api:generate --validate-only ``` The generated resources will be created in `src/Generated/Api/{ApiType}/` directory. ## 6. Install assets for the API Platform documentation interface Install the necessary assets for API Platform to function correctly: ### For Glue application ```bash docker/sdk cli glue assets:install public/Glue/assets --symlink ``` ### For GlueStorefront ```bash docker/sdk cli GLUE_APPLICATION=GLUE_STOREFRONT glue assets:install public/GlueStorefront/assets/ --symlink ``` ### For GlueBackend ```bash docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND glue assets:install public/GlueBackend/assets/ --symlink ``` {% info_block warningBox "Required step" %} The `assets:install` command is required to copy the necessary assets (CSS, JavaScript, images) for the API Platform documentation interface. Without this step, the API documentation UI will not display correctly. {% endinfo_block %} ## 7. Clear caches After generation and asset installation, clear application caches: ```bash # Clear all caches console cache:clear # Build Symfony container cache console container:build ``` ## Verification To verify your integration: 1. **Debug available resources:** ```bash # List all API resources docker/sdk cli glue api:debug --list # Inspect specific resource docker/sdk cli glue api:debug access-tokens --api-type=storefront ``` 2. **Access API documentation:** - Glue: `https://glue.your-domain/` - GlueStorefront: `https://glue-storefront.your-domain/` - GlueBackend: `https://glue-backend.your-domain/` The interactive OpenAPI documentation interface will be displayed at the root URL of each application. Depending on the environment of the application (development or production), the documentation interface may be enabled or disabled by default. Currently, it is only enabled in development (docker.dev) environments. You can enable/disable this interface by configuring the settings in your `api_platform.php` configuration files. ## Next steps - [API Platform](/docs/dg/dev/architecture/api-platform.html) - Overview and concepts - [Enablement](/docs/dg/dev/architecture/api-platform/enablement.html) - Create your first API resource - [Resource Schemas](/docs/dg/dev/architecture/api-platform/resource-schemas.html) - Resource Schemas - [Validation Schemas](/docs/dg/dev/architecture/api-platform/validation-schemas.html) - Validation Schemas

Enable Google Material Icons in Back Office

Wed, 28 Jan 2026 09:55:40 +0000

This guide explains how to enable Google Material Icons in the Spryker Cloud Commerce OS Back Office.
By enabling these icons, you can modernize your admin interface and improve its overall appearance.

To display a Material Icon in your templates, use the following HTML markup:

<span class="material-symbols-outlined">search</span>

material-symbols-outlined — defines the Material Icon style.
search — defines the name of the icon to render.

You can explore all available icons on the Google Material Icons website.

Steps to Enable Material UI Icons

1. Update the Required Module

Update the spryker/gui module to version 4.8.0 or higher:

composer update spryker/gui:"^4.8.0"

2. Configure the Default Icon Type

Create or update the GuiConfig class on the project level to set the default icon type to google-material:

src/Pyz/Zed/Gui/GuiConfig.php

<?php

declare(strict_types = 1);

namespace Pyz\Zed\Gui;

use Spryker\Zed\Gui\GuiConfig as SprykerGuiConfig;

class GuiConfig extends SprykerGuiConfig
{
    protected const string NAVIGATION_ICONS_TYPE_DEFAULT = 'google-material';
}

Available options:

'font-awesome' — the classic icon set (default)
'google-material' — the new Material UI icons

3. Register the Twig Plugin

src/Pyz/Zed/Twig/TwigDependencyProvider.php

<?php

declare(strict_types = 1);

namespace Pyz\Zed\Twig;

use Spryker\Zed\Gui\Communication\Plugin\Twig\NavigationIconsTypeTwigPlugin;
use Spryker\Zed\Twig\TwigDependencyProvider as SprykerTwigDependencyProvider;

class TwigDependencyProvider extends SprykerTwigDependencyProvider
{
    /**
     * @return array<\Spryker\Shared\TwigExtension\Dependency\Plugin\TwigPluginInterface>
     */
    protected function getTwigPlugins(): array
    {
        return [
            // ...existing plugins...
            new NavigationIconsTypeTwigPlugin(),
        ];
    }
}

To use Material Icons in the Back Office sidebar navigation, update the config/Zed/navigation.xml file.
Add or modify the <icon> elements for each navigation item with the desired Material Icon name.

Example:

<?xml version="1.0"?>
<config>
    <dashboard>
        <label>Dashboard</label>
        <title>Dashboard</title>
        <bundle>dashboard</bundle>
        <controller>index</controller>
        <action>index</action>
        <icon>grid_view</icon>
    </dashboard>

    <sales>
        <label>Sales</label>
        <uri>/sales</uri>
        <title>Sales</title>
        <icon>local_mall</icon>
        <pages>
            <order-list>
                <label>Orders</label>
                <title>Orders</title>
                <bundle>sales</bundle>
                <controller>index</controller>
                <action>index</action>
            </order-list>
        </pages>
    </sales>
</config>

Tip

You can browse available icon names at [fonts.google.com/icons](https://fonts.google.com/icons). For suggested icons, see the example configuration in the [Spryker B2B Demo Marketplace repository](https://github.com/spryker-shop/b2b-demo-marketplace/blob/master/config/Zed/navigation.xml).

After updating your navigation configuration, rebuild the navigation cache with the following command:

docker/sdk console navigation:build-cache

Result

After you complete these steps, the Spryker Back Office displays Google Material Icons throughout the sidebar navigation, resulting in a clean, modern, and professional appearance.

Troubleshooting Dependency Injection

Wed, 28 Jan 2026 08:38:28 +0000

This document describes common issues and solutions when working with Symfony's Dependency Injection component in Spryker. ## Container compilation failures ### Unknown classes from core **Problem:** The container compilation fails with an error about an unknown class from a Spryker core module. **Example error:** ```php The service "Spryker\Zed\Product\Business\ProductFacade" has a dependency on a non-existent service "Spryker\Zed\Product\Business\SomeInternalService". ``` **Cause:** You're trying to autowire a class from a core module that doesn't have a pre-compiled container or isn't configured in your `ApplicationServices.php`. **Solution 1 - Register the service manually:** Add the missing service to your `config/Zed/ApplicationServices.php`: ```php services() ->defaults() ->autowire() ->public() ->autoconfigure(); // Register the missing core service $services->set(ProductFacadeInterface::class, ProductFacade::class); }; ``` **Solution 2 - Create a project-level extension:** Create your own class that extends the core service and register it: ```php set(CustomerFacadeInterface::class, \Pyz\Zed\Customer\Business\CustomerFacade::class); ``` ### Scalar constructor arguments **Problem:** Container compilation fails when a service constructor has scalar type hints (int, string, bool, float). **Example error:** ```php Cannot autowire service "Pyz\Zed\MyModule\MyService": argument "$timeout" of method "__construct()" is type-hinted "int", you should configure its value explicitly. ``` **Cause:** Autowiring cannot determine what value to inject for scalar types. The container needs explicit configuration. **Solution 1 - Configure the argument explicitly:** ```php services() ->defaults() ->autowire() ->public() ->autoconfigure(); $services->set(MyService::class) ->arg('$timeout', 30); }; ``` **Solution 2 - Use a configuration object (recommended):** Instead of scalar arguments, create a value object: ```php true, // Often uses many transfer objects 'ProductPageSearch' => true, 'ProductStorage' => true, ]; foreach ($projectModules as $moduleTransfer) { if (isset($excludedModuleConfiguration[$moduleTransfer->getName()])) { continue; // Skip this module } // ... load module services } ``` ### Argument is type-hinted "array" **Problem:** The container compilation fails with an error about configuring values explicitly. **Example error:** ```php Cannot autowire service "Spryker\Glue\AuthRestApi\Processor\AccessTokens\AccessTokenUserFinder": argument "$restUserExpanderPlugins" of method "__construct()" is type-hinted "array", you should configure its value explicitly. ``` **Cause:** Symfony can't automatically detect which classes it should inject as dependency for array's. There is a type-hint to an array of interfaces but which ones should be added here can't be automatically detected. **Solution - Use the Stack Attribute:** ```php $restUserExpanderPlugins */ #[Stack( dependencyProvider: AuthRestApiDependencyProvider::class, dependencyProviderMethod: 'getRestUserExpanderPlugins', provideToArgument: '$restUserExpanderPlugins', )] public function __construct( protected array $restUserExpanderPlugins ) {} } ``` During compilation the `\Spryker\Service\Container\Pass\StackResolverPass` understands this configuration and will inject the array dependency through this configuration. When the class is requested from the container, the container knows that it has to pass the returned array from the `AuthRestApiDependencyProvider::getRestUserExpanderPlugins()` method to the argument `$restUserExpanderPlugins`. Multiple Stack attributes can be used on a class constructor. ## Debugging When you need to understand how the container resolves services or troubleshoot issues, debug into these key classes: ### ContainerDelegator - Service resolution **Location:** `Spryker\Service\Container\ContainerDelegator` **Purpose:** Tracks which service from which container gets resolved. **Key methods to debug:** - `get(string $id)`: Main entry point for service resolution (line 94) - `findInProjectContainer(string $id)`: Searches for services in project container (line 226) - `getPartsFromId(string $id)`: Extracts namespace, application, module from service ID (line 430) **What to look for:** - Check `$this->resolvedServices` to see already resolved services - Inspect `$this->containers` to see attached containers (project_container, application_container) - Review `$this->checkedContainer` for which containers were searched **Debug example:** ```php // Add breakpoint in ContainerDelegator::get() public function get(string $id, int $invalidBehavior = self::EXCEPTION_ON_INVALID_REFERENCE): ?object { // Check here what $id is being requested // Inspect $this->containers to see available containers // Step through to see resolution logic } ``` ### ControllerResolver - Controller discovery **Location:** `Spryker\Shared\Router\Resolver\ControllerResolver` **Purpose:** Resolves controller classes from route definitions and injects dependencies. **Key methods to debug:** - `getController(Request $request)`: Main entry point for controller resolution (line 37) - `getControllerFromString()`: Handles string-based controller definitions (line 66) - `injectContainerAndInitialize()`: Injects dependencies into controller (line 170) **What to look for:** - Check how the controller string is parsed - See if controller is found in ContainerDelegator via `$globalContainer->has($controller)` (line 75) - Verify if controller is being instantiated via DI or traditionally **Debug example:** ```php // Add breakpoint in ControllerResolver::getController() public function getController(Request $request): callable|false { $controller = $request->attributes->get('_controller'); // Check $controller value // Step through to see if it's resolved from container } ``` ### Kernel - Application setup **Location:** `Spryker\Shared\Application\Kernel` **Purpose:** Sets up the application, manages ApplicationPlugins, and boots the container. **Extends:** `Symfony\Component\HttpKernel\Kernel` **Uses:** `Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait` **Key methods to debug:** - `__construct()`: Initial setup, attaches containers to ContainerDelegator (line 44) - `boot()`: Boots Symfony container and ApplicationPlugins (line 130) - `build()`: Registers compiler passes (line 248) - `configureContainer()`: Loads service configuration files (line 209) **Important Symfony base class methods:** Refer to Symfony documentation for these methods: - [Symfony HttpKernel Component](https://symfony.com/doc/current/components/http_kernel.html) - [MicroKernelTrait](https://symfony.com/doc/current/configuration/micro_kernel_trait.html) **What to look for:** - Check which ApplicationPlugins are registered - Inspect `$this->container` to see if it's ContainerDelegator or Symfony container - Review which compiler passes are added - Verify service configuration file loading **Debug example:** ```php // Add breakpoint in Kernel::boot() public function boot(): void { // Check if container is already compiled // See which ApplicationPlugins are being booted // Inspect ContainerDelegator attachments } ``` ### Application - Request handling **Location:** `Spryker\Shared\Application\Application` **Purpose:** Sets up and boots ApplicationPlugins, selects the correct Kernel, and handles requests via HttpKernel. **Key methods to debug:** - `handle()`: Main request handling entry point (line 180) - `registerPlugins()`: Registers all ApplicationPlugins (line 100) - `registerPluginsAndBoot()`: Registers and boots ApplicationPlugins (line 131) **What to look for:** - Check which ApplicationPlugins are registered - See when the Kernel is created and booted - Verify container setup and switching **Debug example:** ```php // Add breakpoint in Application::handle() public function handle(Request $request, int $type = self::MASTER_REQUEST, bool $catch = true): Response { // Check if kernel exists in container // See how container is set up // Verify plugin registration timing } ``` ### Common debugging workflow 1. **Start with ContainerDelegator** - Check if the service is being requested and from which container 2. **Move to ControllerResolver** - If controller-related, see how it's being resolved 3. **Check Kernel setup** - Verify ApplicationPlugins and container configuration 4. **Review Application flow** - Understand the complete request lifecycle ### Enabling debug output To see detailed container compilation information, set the debug flag to true: In your `config/Shared/config_default.php`: ```php $config[ApplicationConstants::ENABLE_APPLICATION_DEBUG] = true; ``` This enables: - Container cache verification - Detailed compiler pass output - Service resolution logging ## Additional tips ### Clear application cache If you encounter container compilation issues or suspect the cache is stale, clear the cache for the affected application. **Clear cache for Zed:** ```bash docker/sdk cli vendor/bin/console cache:clear ``` **Clear cache for Glue API:** ```bash docker/sdk cli vendor/bin/glue cache:clear ``` **Clear cache for Glue Storefront API:** ```bash docker/sdk cli GLUE_APPLICATION=GLUE_STOREFRONT vendor/bin/glue cache:clear ``` **Clear cache for Glue Backend API:** ```bash docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND vendor/bin/glue cache:clear ``` These commands clear the compiled container cache and force a fresh compilation on the next request. ### Verify container cache If you need to manually inspect or remove specific container cache files: ```bash # Clear the container cache rm -rf data/cache/Zed/*/appSpryker_Shared_Application_Kernel* # Rebuild the container console container:build ``` ### Check service availability To verify if a service is available in the container, check the compiled container file: ```bash # Location of compiled container data/cache/Zed/{environment}/appSpryker_Shared_Application_Kernel_{Application}_{Environment}Container.php ``` Search for your service ID in this file to see if it was registered correctly. ### Module compilation check If a core module doesn't have a container, check if it exists: ```bash # Core module container location vendor/spryker/{module-name}/src/Spryker/Zed/{ModuleName}/Service/Container/{ModuleName}ServiceContainer.php ``` ## Next steps - [Implementation and usage](/docs/dg/dev/architecture/dependency-injection/implementation-and-usage.html) - [Best practices for Dependency Injection](/docs/dg/dev/architecture/dependency-injection/best-practices.html) - [Dependency injection](/docs/dg/dev/architecture/dependency-injection.html)

Troubleshooting installation

Wed, 28 Jan 2026 08:38:28 +0000

This section describes common issues and solutions related to installing Spryker locally. ## Clear application cache If you encounter compilation errors during installation or after setup, clear the cache for the affected application. **Clear cache for Zed:** ```bash docker/sdk cli vendor/bin/console cache:clear ``` **Clear cache for Glue API:** ```bash docker/sdk cli vendor/bin/glue cache:clear ``` **Clear cache for Glue Storefront API:** ```bash docker/sdk cli GLUE_APPLICATION=GLUE_STOREFRONT vendor/bin/glue cache:clear ``` **Clear cache for Glue Backend API:** ```bash docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND vendor/bin/glue cache:clear ``` These commands clear the compiled container cache and resolve most cache-related installation issues. ## Topics - [Clear application cache](#clear-application-cache) - [An error during front end setup](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/an-error-during-front-end-setup.html) - [Demo data was imported incorrectly](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/demo-data-was-imported-incorrectly.html) - [Docker daemon is not running](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/docker-daemon-is-not-running.html) - [docker-sync cannot start](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/docker-sync-cannot-start.html) - [Error 403 No valid crumb was included in the request](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/error-403-no-valid-crumb-was-included-in-the-request.html) - [Node Sass does not yet support your current environment](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/node-saas-does-not-yet-support-your-current-environment.html) - [Setup of new indexes throws an exception](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/setup-of-new-indexes-throws-an-exception.html) - [Unable to bring up Mutagen Compose sidecar service](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/unable-to-bring-up-mutagen-compose-sidecar-service.html) - [Vendor folder synchronization error](/docs/dg/dev/set-up-spryker-locally/troubleshooting-installation/vendor-folder-synchronization-error.html)

API Platform Enablement

Tue, 27 Jan 2026 13:57:52 +0000

This document describes how to create and enable API Platform resources in your Spryker project.

Prerequisites

Before creating API resources, ensure you have:

Integrated API Platform as described in How to integrate API Platform
Configured your application’s bundle files
Configured API types as described in API Platform Configuration

Creating your first API resource

1. Define the resource schema

Create a schema file that defines your API resource structure. Schemas should be placed in resources/api/{api-type}/ directory within your module.

Example: Customer resource for Back Office API

src/Pyz/Glue/Customer/resources/api/backend/customers.yml

# yaml-language-server: $schema=../../../../../vendor/spryker/api-platform/resources/schemas/api-resource-schema-v1.json

resource:
    name: Customers
    shortName: Customer
    description: "Customer resource for backend API"

    provider: "Pyz\\Glue\\Customer\\Api\\Backend\\Provider\\CustomerBackendProvider"
    processor: "Pyz\\Glue\\Customer\\Api\\Backend\\Processor\\CustomerBackendProcessor"

    paginationEnabled: true
    paginationItemsPerPage: 10

    operations:
        - type: Post
        - type: Get
        - type: GetCollection
        - type: Patch
        - type: Delete

    properties:
        idCustomer:
            type: integer
            description: "The unique identifier of the customer."
            writable: false

        email:
            type: string
            description: "The email address of a user or contact."
            openapiContext:
                example: "test@spryker.com"

        firstName:
            type: string
            description: "The first name of a person."
            openapiContext:
                example: "John"

        lastName:
            type: string
            description: "The last name of a user or customer."
            openapiContext:
                example: "Doe"

        customerReference:
            type: string
            description: "A unique reference for a customer."
            writable: false
            identifier: true

2. Create validation schema

Define validation rules in a separate validation schema file:

src/Pyz/Glue/Customer/resources/api/backend/customers.validation.yml

post:
    email:
        - NotBlank
        - Email

    firstName:
        - NotBlank
        - Length:
              max: 100

    lastName:
        - NotBlank
        - Length:
              max: 100

patch:
    email:
        - Optional:
              constraints:
                  - NotBlank
                  - Email

    firstName:
        - Optional:
              constraints:
                  - NotBlank
                  - Length:
                        max: 100

3. Implement the Provider

The Provider is responsible for fetching data (GET operations). Implement the ProviderInterface:

src/Pyz/Glue/Customer/Api/Backend/Provider/CustomerBackendProvider.php

<?php

namespace Pyz\Glue\Customer\Api\Backend\Provider;

use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\Pagination\TraversablePaginator;
use ApiPlatform\State\ProviderInterface;
use Pyz\Glue\Customer\Business\CustomerFacadeInterface;
use Generated\Api\Backend\CustomersBackendResource;

class CustomerBackendProvider implements ProviderInterface
{
    public function __construct(
        private CustomerFacadeInterface $customerFacade,
    ) {
    }

    /**
     * @param \ApiPlatform\Metadata\Operation $operation
     * @param array<string, mixed> $uriVariables
     * @param array<string, mixed> $context
     *
     * @return object|array<object>|null
     */
    public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null
    {
        // Single resource (GET /customers/{id})
        if (isset($uriVariables['customerReference'])) {
            return $this->getCustomer($uriVariables['customerReference']);
        }

        // Collection (GET /customers)
        return $this->getCustomers($context);
    }

    private function getCustomer(string $customerReference): ?CustomersBackendResource
    {
        $customerTransfer = $this->customerFacade->findCustomerByReference($customerReference);

        if ($customerTransfer === null) {
            return null;
        }

        // Map to API resource
        $resource = new CustomersBackendResource();
        $resource->fromArray($customerTransfer->toArray());

        return $resource;
    }

    private function getCustomers(array $context): TraversablePaginator
    {
        $filters = $context['filters'] ?? [];
        $page = (int) ($filters['page'] ?? 1);
        $itemsPerPage = (int) ($filters['itemsPerPage'] ?? 10);

        $customerCollection = $this->customerFacade->getCustomerCollection($page, $itemsPerPage);

        $resources = [];
        foreach ($customerCollection->getCustomers() as $customerTransfer) {
            $resource = new CustomersBackendResource();
            $resource->fromArray($customerTransfer->toArray());

            $resources[] = $resource;
        }

        return new TraversablePaginator(
            new \ArrayObject($resources),
            $page,
            $itemsPerPage,
            $customerCollection->getTotalCount()
        );
    }
}

4. Implement the Processor

The Processor handles data modifications (POST, PUT, PATCH, DELETE). Implement the ProcessorInterface:

src/Pyz/Glue/Customer/Api/Backend/Processor/CustomerBackendProcessor.php

<?php

namespace Pyz\Glue\Customer\Api\Backend\Processor;

use ApiPlatform\Metadata\Delete;
use ApiPlatform\Metadata\Operation;
use ApiPlatform\Metadata\Patch;
use ApiPlatform\Metadata\Post;
use ApiPlatform\State\ProcessorInterface;
use Pyz\Glue\Customer\Business\CustomerFacadeInterface;
use Generated\Api\Backend\CustomersBackendResource;

class CustomerBackendProcessor implements ProcessorInterface
{
    public function __construct(
        private CustomerFacadeInterface $customerFacade,
    ) {
    }

    /**
     * @param mixed $data
     * @param \ApiPlatform\Metadata\Operation $operation
     * @param array<string, mixed> $uriVariables
     * @param array<string, mixed> $context
     *
     * @return mixed
     */
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
    {
        if ($operation instanceof Delete) {
            $this->customerFacade->deleteCustomer($uriVariables['customerReference']);
            return null;
        }

        if ($operation instanceof Post) {
            $customerTransfer = $this->mapToTransfer($data);
            $savedCustomer = $this->customerFacade->createCustomer($customerTransfer);
            return $this->mapToResource($savedCustomer);
        }

        if ($operation instanceof Patch) {
            $customerTransfer = $this->mapToTransfer($data);
            $customerTransfer->setCustomerReference($uriVariables['customerReference']);
            $updatedCustomer = $this->customerFacade->updateCustomer($customerTransfer);
            return $this->mapToResource($updatedCustomer);
        }

        return null;
    }

    private function mapToTransfer(CustomersBackendResource $resource): CustomerTransfer
    {
        $transfer = new CustomerTransfer();
        $transfer->fromArray($resource->toArray(), true);

        return $transfer;
    }

    private function mapToResource(CustomerTransfer $transfer): CustomersBackendResource
    {
        $resource = new CustomersBackendResource();
        $resource->fromArray($transfer->toArray());

        return $resource;
    }
}

5. Generate the resource

Run the generation command to create the API resource class:

docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND glue api:generate backend

This generates:

src/Generated/Api/Backend/CustomersBackendResource.php

The generated class includes:

API Platform attributes (#[ApiResource], #[ApiProperty])
Validation constraints (#[Assert\NotBlank], #[Assert\Email], etc.)
Public properties for all defined fields
Getters and setters
toArray() and fromArray() methods

6. Register services in the Dependency Injection container

Make your Provider and Processor available through dependency injection: markdo config/Glue/ApplicationServices.php

<?php

use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;

return static function (ContainerConfigurator $configurator): void {
    $services = $configurator->services()
        ->defaults()
        ->autowire()
        ->public()
        ->autoconfigure();

    // Auto-discover services from your project modules
    $services->load('Pyz\\Glue\\', '../../../src/Pyz/Glue/');
};

7. Test your API

After generation, your API is immediately available:

# List all customers
GET /customers

# Get single customer
GET /customers/{customerReference}

# Create customer
POST /customers
{
  "email": "john@example.com",
  "firstName": "John",
  "lastName": "Doe"
}

# Update customer
PATCH /customers/{customerReference}
{
  "firstName": "Jane"
}

# Delete customer
DELETE /customers/{customerReference}

Creating CodeBucket-specific resources

CodeBucket support enables you to create Code Bucket-specific API resource variants that are resolved at runtime based on the APPLICATION_CODE_BUCKET environment constant.

When to use CodeBucket resources

Create CodeBucket variants when you need:

Code Bucket-specific properties (EU GDPR fields, tax rates, compliance data)
Code Bucket-specific validation rules (country-specific requirements)
Country-specific business logic
Feature variations per Code Bucket

Quick example

Base resource:

src/Pyz/Glue/Customer/resources/api/backend/customers.yml

resource:
  name: Customers
  shortName: Customer

  operations:
    - type: Get
    - type: Post

  properties:
    customerReference:
      type: string
      identifier: true
    email:
      type: string
    firstName:
      type: string

EU-specific variant:

src/Pyz/Glue/CustomerEU/resources/api/backend/customers.resource.yml

resource:
  name: Customers
  shortName: Customer
  codeBucket: EU
  
  operations:
    - type: Get
    - type: Post

  properties:
    customerReference:
      type: string
      identifier: true
    email:
      type: string
    firstName:
      type: string

    # EU-specific properties
    gdprConsentDate:
      type: string
      description: "Date of GDPR consent"
    dataPrivacyOfficerEmail:
      type: string
      description: "Data privacy officer contact"

Generate resources:

docker/sdk cli GLUE_APPLICATION=GLUE_BACKEND glue api:generate backend

This generates:

CustomersBackendResource.php (base)
CustomersEUBackendResource.php (with CODE_BUCKET = 'EU')

Runtime behavior:

Request to glue.eu.spryker.local/customers → Uses CustomersEUBackendResource
Request to glue.de.spryker.local/customers → Uses CustomersBackendResource (fallback)
Request to glue.at.spryker.local/customers → Uses CustomersBackendResource (or CustomersATBackendResource if variant exists)

For a comprehensive guide including Provider implementation and advanced scenarios, see CodeBucket Support.

API types and use cases

Spryker supports multiple API types for different use cases:

Storefront API (Glue)

API Type: storefront
Module location: src/Spryker/{Module}/resources/api/storefront/
Generated namespace: Generated\Api\Storefront
Use cases: Customer-facing APIs, mobile apps, PWAs

Back Office API (Glue)

API Type: backend
Module location: src/Pyz/Glue/{Module}/resources/api/backend/
Generated namespace: Generated\Api\Backend
Use cases: Admin panels, internal tools, ERP integrations

Merchant Portal API

API Type: merchant-portal
Module location: src/Spryker/{Module}/resources/api/merchant-portal/
Generated namespace: Generated\Api\MerchantPortal
Use cases: Marketplace merchant interfaces

Schema layering and inheritance

API Platform supports multi-layer schema definitions with automatic merging:

Core layer

vendor/spryker/customer/resources/api/backend/customer.yml - Base definition

Feature layer

src/SprykerFeature/CustomerRelationManagement/resources/api/backend/customer.yml - Feature enhancements

Project layer

src/Pyz/Glue/Customer/resources/api/backend/customer.yml - Project customizations

The generator automatically merges these schemas with project layer taking precedence.

Debugging resources

Use the debug command to inspect resources:

# List all resources
docker/sdk cli glue  api:debug --list

# Show resource details
docker/sdk cli glue  api:debug customers --api-type=backend

# Show merged schema
docker/sdk cli glue  api:debug customers --api-type=backend --show-merged

# Show source files
docker/sdk cli glue  api:debug customers --api-type=backend --show-sources

Next steps

Resource Schemas - Deep dive into resource schema syntax
Validation Schemas - Define validation rules for your resources
CodeBucket Support - Create Code Bucket-specific resources
API Platform Testing - Learn how to write tests for your API resources
Troubleshooting - Common issues and solutions

Customer Login overview

Tue, 27 Jan 2026 08:46:40 +0000

The Customer Login feature with an enhanced secure password policy lets you prevent brute-force login attacks by configuring your project in the following ways:

Block a Storefront user account for some time after a certain number of login attempts.
Enforce the use of strong passwords by defining requirements for a password, like its length and allowed and forbidden characters.

You can define separate settings for a Storefront user and agent.

Demo Shop default configuration

The feature’s default configuration in the Spryker Demo Shop is as follows. When a user tries to log in and the number of unsuccessful login attempts reaches the preset limit (11 attempts for a Storefront user and 10 for an agent), the user account is locked out for some time (5 minutes for a Storefront user and 6 for an agent). After the last unsuccessful attempt, the user is notified that the ban is applied, and the user cannot log in until the ban expires.

To minimize login issues for real customers, the ban is applied by the IP address, which means you can log in to the same user account from one IP address while being locked out of another IP address. All information about blocked accounts is stored in key-value store (Redis or Valkey).

When registering an account or changing an old password in the Demo Shop, the password must contain a combination of alphabetic, numeric, and special characters. The alphabetic characters must also be of mixed case (for example, one lower case and one upper case), and the password length must be from 8 to 64 characters.

Security concerns

In order to enable brute-force protection, follow this security release.

Release notes 202512.0

Tue, 27 Jan 2026 08:41:50 +0000

Spryker Cloud Commerce OS is an end-to-end solution for digital commerce. This document contains a business-level description of new features and improvements. For information about installing Spryker, see [Getting started guide](/docs/dg/dev/development-getting-started-guide.html). ## Expanded B2B commerce capabilities ### Self-Service Portal models for asset-based catalogs ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) Self-Service Portal (SSP) models help operators manage complex equipment structures and help customers find compatible spare parts and service products faster in asset-based catalogs. ![Self-Service Assets](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/all/releases/release-notes-202512.0.md/SSP-assets-page.png) **What are SSP models?** SSP models let you group multiple assets into a single product family (for example, a machine type or series). Assets in the SSP are now directly connected to the product catalog, including compatible spare parts and service offerings, making the Self-Service Portal fully transactional. For each model, a curated list of compatible spare parts and services can be maintained. When a customer browses the catalog or opens a product detail page, results are automatically filtered to show only items compatible with the selected model or asset, enabling accurate identification and immediate purchase. **Key capabilities:** - Group assets that belong to the same machinery type or generation. - Maintain compatibility at the model level instead of the individual asset level. - Assign spare part lists to models so buyers see only relevant products. - Filter the storefront catalog by model, asset, serial number, or model code. - Run compatibility checks from the product detail page. - Support transactional self-service so customers purchase the correct items faster. **Business benefits:** - Improve spare part identification accuracy in self-service journeys. - Reduce maintenance effort for asset-to-product mapping. - Speed up after-sales purchases with asset-specific filtering. - Scale after-sales revenue with automation and self-service. Models is available in the Self-Service Portal Back Office and Storefront. **Documentation:** - [Self-Service Portal Models](/docs/pbc/all/self-service-portal/latest/ssp-model-management-feature-overview) - [Self-Service Portal Asset Based Catalog](/docs/pbc/all/self-service-portal/latest/ssp-asset-based-catalog-feature-overview) - [Self-Service Portal](/docs/pbc/all/self-service-portal/latest/self-service-portal) ### Merchant Portal file-based product import is now generally available ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) File-based product import in Merchant Portal moves from Early Access to General Availability, with reliability and UX improvements based on customer feedback. ![merchant-portal-import](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/all/releases/release-notes-202507.0.md/merchant-portal-import.png) **Key capabilities** - Provide clear post-import results (success and errors) in the UI or as a downloadable CSV. - Strengthen validations and safeguards to reduce failed imports and incorrect updates. - Improve import consistency for production usage, including better messaging and translations where applicable. **Business benefits** - Faster merchant onboarding and ongoing catalog maintenance at scale. - Lower support effort thanks to clearer feedback and import logs. - Higher confidence running bulk imports in production environments. **Documentation:** - [Merchant Portal Import Products](/docs/pbc/all/product-information-management/latest/marketplace/manage-in-the-merchant-portal/import-products-ui) - [Merchant Portal Import Product Offers](/docs/pbc/all/offer-management/latest/marketplace/import-offers-ui) - [Install Merchant Portal Product Data Import](/docs/pbc/all/product-information-management/latest/marketplace/install-and-upgrade/install-features/install-the-merchant-product-data-import-feature) - [Install Product Offer Data Import](/docs/pbc/all/offer-management/latest/marketplace/install-and-upgrade/install-features/install-the-marketplace-merchant-portal-product-offer-data-import-feature) ### Merchant Self-Registration ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) Merchant onboarding is simplified with a storefront entry point while keeping marketplace quality and compliance under control through Back Office review and approval. ![merchant-self-registration](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/all/releases/release-notes-202512.0.md/Merchant-Self-Registration.png) **Key capabilities:** - Added a storefront-led merchant self-registration flow, allowing prospective merchants to submit an application which can be reviewed and approved in Back Office before merchant entities and users are created. **Business benefits:** - Reduced manual onboarding effort and improved consistency of merchant intake. - Faster and more controlled merchant onboarding for marketplace operators. **Documentation:** - [Merchant Self-Registration](/docs/pbc/all/merchant-management/latest/marketplace/merchant-self-registration-feature-overview) - [Install Merchant Self-Registration](/docs/pbc/all/merchant-management/latest/marketplace/install-and-upgrade/install-features/install-the-merchant-self-registration-feature) ### Agent assist order traceability ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Order traceability for Agent Assist flows is improved so operations and support teams can quickly see who submitted an order on behalf of a customer. **Key capabilities:** - Back Office now records and displays the submitting agent email for orders placed via Agent Assist, improving traceability and follow-up efficiency. **Business benefits:** - Faster issue resolution and clearer ownership for agent-created orders. - Improved auditability for Agent Assist flows. **Documentation:** - [Agent Assist](/docs/pbc/all/user-management/latest/base-shop/agent-assist-feature-overview#setting-up-an-agent-user) - [Install Agent Assist](/docs/pbc/all/user-management/latest/base-shop/install-and-upgrade/install-the-agent-assist-feature#install-feature-core) ### Merchant Portal dashboard improvements ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Merchant day to day catalog work is simplified in Merchant Portal by adding a clearer entry point to product management directly from the dashboard. ![merchant-portal-dashboard](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/all/releases/release-notes-202512.0.md/merchant-portal-dashboard.png) **Key capabilities** - Added a Products widget to the Merchant Portal dashboard to improve discoverability of product management. **Business benefits** - Faster access to core catalog workflows for merchants. - Less navigation effort for merchants managing large assortments. ### Storefront merchant profile improvements ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Storefront discovery is improved by making it easier for buyers to navigate from a merchant profile to that merchant's products with the right catalog filters already applied. **Key capabilities** - Added a "Shop Merchant Products" button on the merchant profile page that opens the product catalog with an active merchant filter. **Business benefits** - Faster product discovery for buyers shopping by merchant. - Smoother path from merchant pages to relevant catalog results. ### Clearer UI in Back Office and Storefront ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Core UI patterns are made more consistent to improve scanability, reduce cognitive load, and provide clearer next steps in common workflows. **Key capabilities** - Introduced a global empty state component for tables with two variants: - Implemented a semantic status pill color system (success, warning, error, neutral) for tables and internal pages, with one-line enforcement for better scanability. - Replaced blocking Storefront notification banners with floating toast notifications (stacked, auto-dismiss, responsive positioning). **Business benefits** - Faster scanning and fewer mistakes when working with large datasets. - Clearer guidance when tables are empty, improving task completion. - Less disruptive Storefront messaging that keeps customers in context. ## Spryker AI: Built for Real Enterprise Commerce ### AI Foundation ![early-access](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/early-access.png) AI Foundation is a provider-agnostic integration layer for building AI powered commerce capabilities in a consistent, maintainable way. **Key capabilities:** - New AiFoundation module compatible with Spryker architecture and existing AI related Eco packages. - Multi provider support through a single interface (for example OpenAI, Azure OpenAI, AWS Bedrock, Google Gemini, Anthropic, local providers). - Prompt based client method that supports file attachments for richer use cases. **Business benefits:** - Faster delivery of AI enabled commerce features through a reusable platform layer. - Provider freedom: adopt or switch AI providers without rewriting feature logic, and choose the best provider and model per use case without rewriting code. - Best fit provider per use case: use different providers and models for different needs. - Lower maintenance effort by centralizing AI integration patterns and configuration. **Documentation:** - [AI Foundation](/docs/pbc/all/ai-foundation/latest/ai-foundation.html) - [Use the AiFoundation module](/docs/pbc/all/ai-foundation/latest/ai-foundation.html) ### Spryker AI Commerce: Back Office Smart Product Management ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) ![early-access](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/early-access.png) ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Back Office Smart Product Management now uses AI Foundation as its AI integration layer, replacing the previous direct OpenAI coupling. This gives customers provider and model choice while keeping existing Smart Product Management AI capabilities working.

**Key capabilities:** - Replace direct OpenAI integration in with AI Foundation as the unified AI layer. - Enable provider and model selection based on customer needs (for example different providers for cost, latency, data residency, or model capabilities). **Business benefits:** - Protects existing customer functionality while enabling a standardized path for future AI enhancements. - Reduces future integration effort and maintenance overhead for AI driven product management capabilities. **Documentation:** - [Smart Product Management](/docs/pbc/all/product-information-management/latest/base-shop/third-party-integrations/smart-product-management/smart-product-management) - [Install Smart Product Management](/docs/pbc/all/product-information-management/latest/base-shop/third-party-integrations/smart-product-management/install-smart-product-management) ### Spryker AI Dev SDK ![early-access](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/early-access.png) The AI Dev SDK improves local AI assisted development with an MCP server, Spryker aware context tools, and prompt library integration, so developers and AI assistants can work with accurate project information and reuse the same prompts across teams. ### Key capabilities - Run a local MCP server for your Spryker project and extend it with custom tools and prompts. - Give AI assistants access to Spryker contracts and data structures to reduce guesswork and implementation errors. - Support OMS flow exploration by showing an order's current state and valid transitions, or listing transitions from any given state. - Reuse and generate prompts from the shared Prompt Library via a typed PHP API. - Keep console output integration friendly with quiet execution. **Documentation:** - [AI Dev Overview](/docs/dg/dev/ai/ai-dev/ai-dev-overview.html) - [Configure the AiDev MCP server](/docs/dg/dev/ai/ai-dev/ai-dev-mcp-server.html) ## Open Architecture for the upcoming Innovation ### Reduced boilerplate via Symfony Dependency Injection support ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) Spryker uses the Dependency Inversion Principle to reduce tight coupling, improve unit testability, and provide a clear, extensible architecture. This approach enables autowiring and reduces the need for repetitive `Factory` and `DependencyProvider` wiring. This approach streamlines development and remains compatible with Symfony Dependency Injection conventions and tooling.

**Key capabilities:** - Reduced manual dependency wiring in your project code. - Improved compatibility with Symfony bundles and Symfony Dependency Injection tooling, such as container introspection. Tools like `debug:container` help you visualize all services. - Self-explanatory, declarative configuration. - High performance through compiled and cached dependency injection. **Business benefits:** - **Code autowiring**: Reduce the boilerplate code you write and maintain by using Symfony Dependency Injection to automatically connect application components. - **Faster feature delivery** by reducing repetitive scaffolding. - **Easier onboarding** for developers who are already familiar with Symfony conventions. **Documentation:** - [Symfony Dependency Injection](/docs/dg/dev/architecture/dependency-injection.html) - [Symfony Bundles in Spryker](/docs/dg/dev/architecture/symfony-bundles.html) ### API Platform ![early access](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/early-access.png) ![feature](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/feature.png) The **API Platform** integration allows you to define API resources declaratively and automatically generate standards-compliant APIs with minimal manual effort. It reduces boilerplate, enforces consistency, and accelerates API development. ![API Platform](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202512/api-platform-2.6-api.png) **Key capabilities:** - **Declarative API definition**: Define API resources using simple YAML schemas instead of writing repetitive controller and transfer logic. - **Automatic endpoint generation**: Generate endpoints with built-in validation, pagination, and serialization that are ready for production use. - **OpenAPI documentation**: Interactive OpenAPI documentation is generated automatically and stays in sync with your API definitions. - **Consistent data contracts**: Enforce uniform data contracts and operation-specific validation rules across all APIs. - **Clear separation of concerns**: Separate read and write logic using providers and processors for better maintainability and extensibility. **Business benefits:** - **Faster API development**: Reduce boilerplate and repetitive scaffolding, enabling faster feature delivery. - **Easier onboarding**: Simplify API development for new teams and partners by providing clear documentation and structured guidance. **Documentation:** - [API Platform](/docs/dg/dev/architecture/api-platform.html) ### API tooling and integration documentation improvements ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) To make API development and partner onboarding easier, the following improvements are introduced: - Enhanced the API documentation to be more structured and usable, with clearer terminology and guidance for integrations, including better support for exploring APIs and understanding data models. - Enhanced documentation of the **Spryker data model**, including products, attributes, prices, and orders. - Added a publicly available **Postman API collection** package, organized around practical "happy path" use cases and environments.

**Key capabilities:** - Ready-to-run Postman collections for common API flows. - Improved documentation structure and integration guidance for solution partners. **Business benefits:** - Faster API adoption and easier onboarding for developers and partners. - Reduced integration effort and fewer misunderstandings for partners and new teams. **Documentation:** - [Integrations Documentation Portal](/docs/integrations/integrate-with-spryker.html) - [Integrations Catalog](/docs/integrations/third-party-integrations.html) - [Interactive API Playground](/docs/integrations/spryker-glue-api/storefront-api/api-references/storefront-api-marketplace-b2b-demo-shop-reference.html). - [API reference with data model descriptions](/docs/integrations/spryker-glue-api/backend-api/api-references/backend-api-marketplace-b2b-demo-shop-reference.html). Expand each resposne to learn more about each field. - [Postman Collections](https://github.com/spryker-community/glue-postman-collections) ### Publish & Synchronize stability and scalability improvements ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Multiple enhancements improve the robustness and transparency of Publish & Synchronize processing, especially when you operate in high-volume environments. **Key capabilities:** - Better resource monitoring and utilization for workers. - Reduced noise from excessive INFO logs and more meaningful statistics and log output. - Improved handling of slow queues through configurable waiting to avoid blocking other processing. - Fixes for known stability issues reported across multiple customers. - Improved error logging in the `queue:worker:start` output, including the queue name, failed message content, and exception chain. - Cleaner processing output that suppresses "all zeros" lines and logs data only when metrics indicate work. - Better ability to adjust processing batch size per queue to isolate problematic messages. **Business benefits:** - More stable P&S execution under load. - Easier scaling and debugging of complex event-driven catalog and offer updates. - Reduced operational overhead for teams running large data volumes. - Faster incident diagnosis for queue-related failures. - Reduced log noise while keeping meaningful operational insights. **Documentation and module releases:** If you are using older versions, we recommend that you update to the referenced releases. - [Implement Publish and Synchronization](/docs/dg/dev/backend-development/data-manipulation/data-publishing/implement-publish-and-synchronization.html) - [Metrics and resource-aware worker configuration](/docs/dg/dev/backend-development/data-manipulation/event/configure-event-queues.html#metrics-and-resource-aware-worker-configuration) - [Newest Publish & Synchronize modules](/docs/dg/dev/guidelines/performance-guidelines/general-performance-guidelines.html#use-the-newest-modules) - [Split heavy entities from publish and event queues](https://api.release.spryker.com/release-group/6027) - [Batch processing of Propel entities](/docs/dg/dev/guidelines/performance-guidelines/performance-guidelines-batch-processing-propel-entities.html) ### Performance improvements ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Rendering of product items, cart pages, and URL resolution database queries has been optimized. **Key capabilities:** - Reduced repeated per-item loading patterns that previously caused multiple separate search calls for the cart, catalog listings, and PDP carousels. - Improved widget and template behavior to avoid N-times Elasticsearch request patterns in common flows. - Targeted cart performance improvements for large baskets. - Eliminated unnecessary case-insensitive comparisons using `UPPER()` where the database collation is already case-insensitive. - Improved performance for URL lookups in large datasets (reduces long-running queries and CPU pressure). **Business benefits:** - Faster page loads on high-traffic pages such as the cart, catalog, and PDP. - Lower search infrastructure cost by cutting unnecessary requests. - More predictable performance for customers with large carts and catalogs. - Lower database CPU utilization. - Faster request handling for URL-heavy flows (storefront and merchant portal routing scenarios). **Documentation:** - [Product review performance](/docs/dg/dev/guidelines/performance-guidelines/general-performance-guidelines.html#product-review-performance) - [Cart performance configuration](/docs/pbc/all/cart-and-checkout/latest/cart-page-performance-configuration.html#cart-page-performance-configuration) **Module Important technical releases:** - [Cart page performance optimization](https://api.release.spryker.com/release-group/6107) - [UPPER() function optimization for URL lookups](https://api.release.spryker.com/release-group/6124) ### Reliability improvements ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) **Key capabilities:** - **Glue API** - Authentication is improved to avoid overloading JWT token payloads with large, mutable, session-relevant data, such as fine-grained permissions. - The API supports up-to-date permission and state resolution without relying on token reissuance. - **Search**: Error handling in full-text search is improved to ensure that unexpected failures are logged and that users receive a consistent fallback experience. - **OMS**: Order Management System processing is hardened against race conditions in which lock behavior can be unsafe in transactional or fast-response environments. **Business benefits:** - **Glue API**: Reduced risk of header-size-related failures in integrations that use extensive permission sets. - **Search**: Faster production troubleshooting and fewer silent failures. - **OMS**: - Fewer hard-to-reproduce concurrency issues in payment and order update flows. - Increased consistency of order state transitions under parallel event processing. **Module releases:** - [Glue API: Authentication improvements](https://api.release.spryker.com/release-group/6095) - [Search: Improved error handling](https://api.release.spryker.com/release-group/6147) - [OMS: Improved concurrency handling](https://api.release.spryker.com/release-group/5963) ### Infrastructure and runtime upgrades ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) Spryker updates its database support strategy to align MySQL and MariaDB versions with currently supported long-term support (LTS) releases. This change addresses the end of support for MySQL 5.7 and mitigates compatibility issues in production environments. The update also includes changes to other components, such as PHP, RabbitMQ, and Bootstrap. **Key capabilities:** - Aligns supported **MySQL versions with modern LTS releases**, including MySQL 8.4. - Continues support for **MariaDB 11.8** while ensuring secure and up-to-date LTS versions. Incremental rollouts are planned for early 2026. - Enables **Redis compression by default** in demoshops to reduce memory footprint and improve cache efficiency. - Ensures **PHP 8.4 readiness** through updates across modules and supporting tooling. - Adds **RabbitMQ 4.1 support** to keep deployments current and benefit from performance improvements. - Adds **Bootstrap 5** by default in Back Office. **Business benefits:** - Reduces memory usage and increases throughput for Valkey and Redis. - Reduces security and operational risks by avoiding end-of-life database versions. - Improved development–production parity, minimizing runtime incompatibilities. - Future-proofs database, PHP, and RabbitMQ support to align with vendor support timelines and enterprise requirements. **Documentation:** - [Docker SDK service configuration](/docs/dg/dev/integrate-and-configure/configure-services.html) - [System Requirements](/docs/dg/dev/system-requirements/latest/system-requirements.html) - [Upgrade Back Office to Bootstrap 5](/docs/pbc/all/back-office/latest/base-shop/install-and-upgrade/upgrade-the-back-office-to-bootstrap-5.html) ### OpenTelemetry Instrumentation Update ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) This update improves OpenTelemetry instrumentation to increase trace accuracy and compatibility across Storefront, Backend API, and GLUE applications. You benefit from resolved naming inconsistencies and improved locale handling for monitoring plugins. **Key capabilities:** - Corrected root span naming for Storefront and Backend API to ensure consistent and meaningful traces. - Fixed compatibility of `MonitoringRequestTransactionEventDispatcherPlugin` with GLUE applications by improving locale resolution logic. - Improved robustness of monitoring setup to better support multiple application contexts without relying on hard-coded application name checks. **Business benefits:** - More accurate and consistent distributed tracing across all application types. - Improved observability for GLUE-based APIs. **Documentation:** - [OpenTelemetry instrumentation](/docs/ca/dev/monitoring/spryker-monitoring-integration/opentelemetry-instrumentation.html) ### Web Profiler enhancements ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) You can now use an improved Web Profiler experience to better support performance investigations and troubleshooting during development: - Fixed an incorrect template path used by `WebProfilerExternalHttpDataCollectorPlugin`. - Added new profiling views for **Yves Ajax** and **Gateway** requests so you can more easily observe request and response flows. - Introduced **Web Profiler improvements: External HTTP Logger**, which includes: - A data collector interface to capture and inspect third-party HTTP calls. - An in-memory logger to record external requests. - Public documentation describing configuration and usage. **Key capabilities:** - Improved visibility into third-party HTTP calls to help you detect bottlenecks, N+1 patterns, and slow dependencies. - Broader profiling coverage across common Yves interaction patterns that you use in storefront development. **Business benefits:** - Faster root-cause analysis during development and quality assurance. - Reduced time spent debugging external integrations and network-related performance regressions during development and testing. **Module releases:** - [Added Yves ajax and ZedRequest profiles to WebProfiler](https://api.release.spryker.com/release-group/6222) - [Fix wrong template name in WebProfilerExternalHttpDataCollectorPlugin](https://api.release.spryker.com/release-group/6210) - [External Custom Requests visible in Web Profiler](https://api.release.spryker.com/release-group/6162) **Documentation:** - [Web Profiler Widget for Yves AJAX](/docs/dg/dev/integrate-and-configure/integrate-development-tools/integrate-web-profiler-widget-for-yves.html) - [Web Profiler for Backend Gateway](/docs/dg/dev/integrate-and-configure/integrate-development-tools/integrate-web-profiler-for-backend-gateway.html) - [WebProfiler Widget monitoring of external HTTP calls](/docs/dg/dev/guidelines/performance-guidelines/external-http-requests.html) ### Faster local development and CI builds through Composer optimization ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) This release introduces a Composer plugin for Demo Shops that splits broad PSR-4 namespaces into **layer- and module-specific** namespaces during autoload generation. This approach reduces autoload scanning overhead and improves rendering and build performance. **Key capabilities:** - Converts general `Spryker\\` namespace mappings into granular mappings, such as `Spryker\\Zed\\\\` and `Spryker\\Yves\\\\`. - Works in both development and production modes and applies consistently across Demo Shops. **Business benefits:** - Improved page rendering speed in Yves and back office during development. - Faster container and image build times in CI and cloud environments, which improves delivery throughput. **Module release:** - [Composer Autoload Plugin](https://github.com/spryker/composer-autoload-plugin/releases/tag/0.1.0) **Installation instructions:** Inside your container execute the following command, answer `yes` when asked to trust this plugin: ```bash composer require spryker/composer-autoload-plugin ``` ### Improved developer productivity and efficiency ![improvement](https://spryker.s3.eu-central-1.amazonaws.com/docs/scos/user/intro-to-spryker/releases/release-notes/improvement.png) **Key capabilities:** - The coding standards remove the need for docblocks that duplicate already declared type information for methods and properties, which reduces noise and maintenance overhead. - A new console helper lets you run a CLI command in a loop for extended periods, which is useful for high-load projects and operational workflows. - You can override Webpack, JavaScript, and SCSS configurations for ZED at the project level. **Business benefits:** - You spend less developer time on non-value-adding code formatting tasks. - You have less need for custom scripts to safely rerun console commands. **Module releases:** - [Adjust sniffer rules for Spryker modules to exclude docblocks from checks](https://api.release.spryker.com/release-group/6097) - [Multi-process run console](/docs/dg/dev/backend-development/cronjobs/multi-process-run-console.html) - [Overriding Webpack, JS, SCSS for ZED on the project level](/docs/dg/dev/frontend-development/latest/zed/overriding-webpack-js-scss-for-zed-on-the-project-level.html)

Import file details: product_abstract.csv

Tue, 27 Jan 2026 08:40:55 +0000

This document describes the `product_abstract.csv` file to configure [Abstract Product](/docs/pbc/all/product-information-management/latest/base-shop/feature-overviews/product-feature-overview/product-feature-overview.html) information in your Spryker Demo Shop. ## Import file dependencies - [category.csv](/docs/pbc/all/product-information-management/latest/base-shop/import-and-export-data/categories-data-import/import-file-details-category.csv.html) - [glossary.csv](/docs/pbc/all/miscellaneous/latest/import-and-export-data/import-file-details-glossary.csv.html) - [tax.csv](/docs/pbc/all/tax-management/latest/base-shop/import-and-export-data/import-file-details-tax-sets.csv.html) ## Import file parameters

| PARAMETER | REQUIRED | TYPE | REQUIREMENTS OR COMMENTS | DESCRIPTION | | --- | --- | --- | --- | --- | | category_key | ✓ | String | | Identifier of category key name. | | category_product_order | | Integer | | Order of the product presentation inside a category. | | abstract_sku | ✓ | String | | SKU identifier of the abstract product. | | name.{ANY_LOCALE_NAME}
Example value: *name.en_US* | ✓ | String |Locale data is dynamic in data importers. It means that ANY_LOCALE_NAME postifx can be changed, removed, and any number of columns with different locales can be added to the .csv files. | Name of the product in the specified location (US for our example). | | url.{ANY_LOCALE_NAME}
Example parameter: *url.en_US* | ✓ | String | | URL page of the product image in the specified location (US for our example). | | attribute_key_{NUMBER}
Example parameter: *attribute_key_1*
| ✓ (if this attribute is defined) | String | | Product attribute key for the attribute. Columns `attribute_key_{NUMBER}` and `value_{NUMBER}` should always come in pair. | | value_{NUMBER}
Example parameter: *value_1*
|✓ (if this attribute is defined) | String | | Product value for the attribute. | | attribute_key_{NUMBER}.{ANY_LOCALE_NAME}
Example value: *attribute_key_1.en_US*
| | String | | Product attribute key, for the first attribute, translated in the specified locale (US for our example). Columns `attribute_key_{NUMBER}.{ANY_LOCALE_NAME}` and `value_{NUMBER}.{ANY_LOCALE_NAME}` should always come in pair. | | value_{NUMBER}.{ANY_LOCALE_NAME}
Example value: *value_1.en_US*
| | String | | Product value for the attribute, translated in the specified locale (US for our example). | | color_code | | String | | Product color code. | | description.{ANY_LOCALE_NAME}
Example value: *description.en_US* | | String | | Product description, translated in the specified locale (US for our example). | | tax_set_name | | String | | Name of the tax set. | | meta_title.{ANY_LOCALE_NAME}
Example value: *meta_title.en_US* | | String | | Meta title of the product in the specified locale (US for our example). | | meta_keywords.{ANY_LOCALE_NAME}
Example value: *meta_keywords.en_US* | | String | | Meta keywords of the product in the specified locale (US for our example). | | meta_description.{ANY_LOCALE_NAME}
Example value: *meta_description.en_US* || String | | Meta description of the product in the specified locale (US for our example). | | new_from | | Date | | To be considered a new product from this presented date. | | new_to | | String | | To be considered a new product until this presented date. | | avalara_tax_code | | String | | [Avalara tax code](/docs/pbc/all/tax-management/latest/base-shop/tax-feature-overview.html#avalara-system-for-automated-tax-compliance) for automated tax calculation. Add this field if Avalara is used for tax management. |

## Additional information For each attribute, where N is a number starting from 1, without gaps, it's mandatory to have both fields: - `attribute_key_N` - `value_N` For each attribute, where N is a number starting from 1, without gaps, it's mandatory to have both fields: - `attribute_key_N.{ANY_LOCALE_NAME}` - `value_N.{ANY_LOCALE_NAME}` The number of attributes is not limited. ## Import template file and content example | FILE | DESCRIPTION | | --- | --- | | [template_product_abstract.csv](https://spryker.s3.eu-central-1.amazonaws.com/docs/pbc/all/product-information-management/base-shop/import-and-export-data/import-file-details-product-abstract.csv.md/Template_product_abstract.csv) | Import file template with headers only. | | [product_abstract.csv](https://spryker.s3.eu-central-1.amazonaws.com/docs/pbc/all/product-information-management/base-shop/import-and-export-data/import-file-details-product-abstract.csv.md/product_abstract.csv) | Exemplary import file with the Demo Shop data. | ## Import command ```bash data:import:product-abstract ```

Spryker Documentation

API Platform

What is API Platform

Architecture overview

Resource generation workflow

Core components

1. Schema files

2. Generated resources

3. State providers and processors

API types

Glue API

GlueStorefront API

GlueBackend API

Merchant Portal API

Multi-layer schema merging

Integration with Spryker architecture

Dependency Injection

Facade integration

Resource generation

Console commands

Debug commands

Features

Automatic OpenAPI documentation

Built-in validation

Pagination support

Operation-specific behavior

Performance

Cache warming

Property-level access control

Comparison with Glue API

Related documentation

Next steps

API Platform Configuration

Configuration file locations

Spryker-specific differences

PHP configuration instead of YAML

Environment variable for conditional settings

Configuration examples

Disable SwaggerUI in production

Disable Doctrine integration

Configure resource mapping paths

Set pagination defaults

Configure supported formats

Complete configuration reference

How to integrate API Platform

Enable Google Material Icons in Back Office

Steps to Enable Material UI Icons

1. Update the Required Module

2. Configure the Default Icon Type

3. Register the Twig Plugin

4. Configure Icons in the Navigation

5. Rebuild the Navigation Cache

Result

Troubleshooting Dependency Injection

Troubleshooting installation

API Platform Enablement

Prerequisites

Creating your first API resource

1. Define the resource schema

2. Create validation schema

3. Implement the Provider

4. Implement the Processor

5. Generate the resource

6. Register services in the Dependency Injection container

7. Test your API

Creating CodeBucket-specific resources

When to use CodeBucket resources

Quick example

API types and use cases

Storefront API (Glue)

Back Office API (Glue)

Merchant Portal API

Schema layering and inheritance

Core layer

Feature layer

Project layer

Debugging resources

Next steps

Customer Login overview

Demo Shop default configuration