Skip to main content
The interface for the config/ endpoint provides comprehensive access to the shop configuration. Through the REST API, configuration data can be retrieved, changed, deleted, or newly created. This includes both global settings and subshop-specific overrides. The configuration is based on predefined schemas that determine which data is permitted. Changes to configuration nodes are validated server-side. The REST API thus allows complete management of the shop configuration — as it is also done via the admin interface.

Supported methods

List of all supported methods.

Structure & use of the configuration via the API

The shop configuration is organized as a directed graph. Each node in this graph represents an independent configuration area and can reference other nodes — for example to specify a language or a country. Each configuration node has a clearly defined type, for which a schema defines which data fields are permitted, what data types they have, and whether a node may be overwritten per subshop or may only exist once. The schemas thus describe the structure of the configuration data, but not its content. The configuration can be fully maintained via the REST API. The admin interface (AI) is also a visual representation of this interface. All functions that can be performed in the interface are also available via the API — such as creating, adapting, deleting, or overwriting configuration nodes. The API is thus particularly suitable for automated management of the configuration, for example as part of:
  • CI/CD processes with clearly defined configuration states,
  • the comparison of settings between test and production systems,
  • or the management of multi-tenant environments with subshop-specific variants.
The REST API thus provides complete access to your shop’s configuration. To determine the fields of a node, the corresponding schema must be loaded via the GET config/schemas/{type} endpoint. The structure of these schemas is described in the properties field. Among other things, it contains the fields id, type, and optionally subtype (e.g. for type: list). id defines the name of the field, while type and subtype indicate what content is expected. type: object indicates a nested structure. Which configuration types are available in the system can be queried in two ways:
  • via GET config/nodeTypes, which provides a compact list of all types,
  • or alternatively via GET config/schemas, which additionally contains the id field.

Valid {type} and {selector} values

The following tables list the valid values that can be used for
  • GET /api/config/schemas/{type} as {type} and
  • GET /api/config/nodes/{selector} as top-level {selector}.
The subnodes, parameters, and examples of the individual areas are not part of this API reference. They are fully described in the Configuration document. This section serves exclusively as orientation for the valid identifiers.

Methods for settings

This section describes the available REST endpoints for managing the shop configuration in the admin area. The interface can be used to retrieve schemas, analyze, check, delete, or completely reset configuration nodes. The configuration is divided into so-called schemas and nodes that are assigned to different areas such as accounts, actions, or system functions. All settings apply either globally or subshop-specifically and can be adjusted depending on the schema and type. The use of the methods requires appropriate read, write, or delete permissions.

GET config/setup

This endpoint retrieves the setup configuration per subshop and stage (e.g. work, active). The return contains technical information such as the host, staticDomain, and contentDomain values, which are required for runtime configuration and content delivery in the respective subshop. This endpoint is primarily intended for internal system or administrative analysis of the current shop setup.

Example

Response

Error codes

GET config/status

This endpoint checks the configuration data for incompleteness and redundancy. It reports whether mandatory fields are missing or whether nodes with identical data exist multiple times.
If no problem is detected, "status": "ok" is returned.
Use requires read permission for configurations.

Example

Response

Response on errors

If errors are detected, the response additionally contains details about the problems found:
The nonUniqueFields and missingRequiredFields fields appear only when corresponding problems are detected.

Error codes

GET config/schemas

This endpoint returns a complete list of all available configuration schemas in the system. A schema describes the structure and properties of a particular configuration type, including, for example, mandatory fields, data types, write protection, overwriteability per subshop, or singleton status. The schemas serve as a technical basis for the validation and editing of configuration data in the admin interface or in automated processes. Use requires read permissions for configuration data.

Example

Response

Error codes

GET config/schemas/{type}

This endpoint can be used to retrieve the schema of a specific configuration type. The schema defines the permitted fields, their data types, optional and mandatory information, and administrative properties such as write protection, deletability, or subshop overwriteability. The information is used by the admin interface and other tools for structural validation and display of configuration entries in the system. Read rights for configuration data are required.

Example

Response

Error codes

GET config/schemas/{type}/defaults

This endpoint can be used to retrieve default parameters of a configuration. The response contains a complete template for the specified configuration type. Read rights for configuration data are required.

Example

Response

Error codes

GET config/nodeTypes

This endpoint returns an overview of all configuration node types present in the system, grouped by schema. For each type, the number of recorded nodes is returned — i.e. how many configuration entries of a given type currently exist. This information is suitable, for example, for inventory taking, validation of the configuration structure, or as a basis for dynamic display in the admin interface. Read permissions for configurations are required for retrieval.

Example

Response

Error codes

Methods for managing nodes in the shop

These methods can be used to read, create, update, or delete configuration nodes in the shop. These are specific instances of settings maintained in the admin area of the shop — e.g. for account login behavior or for consent services such as cookie services. Depending on the type of the underlying schema, a configuration node can either:
  • be defined as a singleton — i.e. only a single node of this type may exist in the shop (e.g. a global login node),
  • or as a multi-node — where multiple nodes of the same type are allowed (e.g. multiple cookie services under general.consentCookieService).
The validity of the data is checked against the corresponding schema when creating or updating. Access requires appropriate permissions for reading, writing, or deleting configurations.

GET config/nodes/{selector}

This method loads the configuration of one or more nodes based on the specified selector. The selector is generally composed of the schema and the node type (e.g. actions.guestRegister or general.consentCookieService). Depending on the node, the endpoint returns either a single configuration element or a list of elements. The response contains the configuration data as well as meta information such as id, type, label, and updatedAt. Read permission for configuration data is required.

Example 1

Response 1

Example 2

Response 2

Error codes

PUT config/nodes/{selector}

This method is used to update a configuration node by its selector. The data content provided is automatically checked against the stored schema. If the schema is violated, a detailed error message is returned. The selector consists of two or three parts separated by dots (e.g. actions.guestRegister or general.consentCookieService.googleAnalytics). The format must be correct so that the configuration can be uniquely identified. If validation fails, the response contains text hints in the detail field. For example: “The value of the field ‘name’ has the wrong type. Expected: string.”. Errors are also listed in the errorContext field. Possible error types (errorContext.{field}.type): WrongType
WrongEnumValue
KeyNotAllowed
IsReadOnly
NotUnique
InvalidSelfAssociation
ServiceNotFound
AssociationWrongType
ServiceMissing
AssociationNotFound
ServiceWrongType
TextMissing
Write permissions for configurations are required.

Example

Request body

Response

Response when validation failed

Error codes

POST config/nodes/{selector}

A configuration node is created; the schema validity is checked. This method creates a new configuration node within the specified schema. It is checked whether the node may be created according to the schema (e.g. not for singleton schemas) and whether the provided data is valid. The structure must match the schema; otherwise, the operation is rejected with a precise error message. The selector always consists of two parts separated by a dot (e.g. general.consentCookieService) that describe the schema type. Additionally, a unique id field must be specified in the request body, which is appended to the selector (e.g. test → results in general.consentCookieService.test). If validation fails, the response contains text hints in the detail field. For example: “The value of the field ‘name’ has the wrong type. Expected: string.”. Errors are also listed in the errorContext field. Possible error types (errorContext.{field}.type): WrongType
WrongEnumValue
KeyNotAllowed
IsReadOnly
NotUnique
InvalidSelfAssociation
ServiceNotFound
AssociationWrongType
ServiceMissing
AssociationNotFound
ServiceWrongType
TextMissing
Create rights for configurations are required.

Example

Request body

Response

Response when validation failed

Error codes

DELETE config/nodes/{selector}

This method deletes an existing configuration node. The specified selector must contain exactly three parts separated by a dot (e.g. general.consentCookieService.google). Before deletion, it is checked whether the corresponding schema permits this — for example whether it is not a singleton or deletion is explicitly forbidden. Delete rights for configurations are required.

Example

Response

Error codes

POST config/nodes/{selector}/move

This method reorders an existing configuration node within its type. Moving is only possible within the same type — a node can only be positioned relative to other nodes of the same type. The new position is defined via exactly one of the two target parameters beforeTarget or afterTarget:
  • With beforeTarget the node is placed directly before the specified target node.
  • With afterTarget the node is placed directly after the specified target node.
Only one of the two parameters may be set at a time. If both or neither are provided, the operation is rejected. Write rights for configurations are required.

Example

Request Body

Response

Error codes

Methods for managing nodes in subshops

The endpoints documented here allow you to specifically overwrite configuration nodes for individual subshops. This makes it possible to implement differing settings per subshop — for example different privacy services or differing email configurations. The methods follow the general schema of node management but extend it with the additional specification of a subshopId.

GET config/nodes/{selector}/overwrites

This method returns a list of all overrides for a specific configuration node. These are configurations that have been specifically adapted for individual subshops. If the node is not overwriteable, an empty JSON array ([]) is returned. If no overrides exist, the result contains an items object with an empty array. Read permissions for configurations are required.

Example

Response

Error codes

GET config/nodes/{selector}/overwrites/{subshopId}

This method loads the subshop-specific override of a specific configuration node. If no override exists for the specified subshop, a corresponding error is returned. If the node is not overwriteable, an error is returned (inappropriateScheme). Read permissions for configurations are required.

Example

Response

Error codes

PUT config/nodes/{selector}/overwrites/{subshopId}

With this method, a configuration node can be overwritten for a specific subshop. The data in the request body must conform to the schema of the original node. Only nodes with the appropriate property can be overwritten. If validation fails, the response contains text hints. For example: “The value of the field ‘name’ has the wrong type. Expected: string.”. Errors are also listed in the errorContext field. Possible error types (errorContext.<field>.type): WrongType
WrongEnumValue
KeyNotAllowed
IsReadOnly
NotUnique
InvalidSelfAssociation
ServiceNotFound
AssociationWrongType
ServiceMissing
AssociationNotFound
ServiceWrongType
TextMissing
Create permissions for configurations are required.

Example

Request body

Response

Response when validation failed

Error codes

DELETE config/nodes/{selector}/overwrites/{subshopId}

This method removes the existing override of a configuration node for a specific subshop. If no valid override is found or deletion is not allowed, a corresponding error message is returned. Delete permissions for configurations are required.

Example

Response

Error codes

Support

Bei technischen Fragen und Hilfestellungen ist unser Support-Team für Sie erreichbar: Zum Kundenportal Bitte senden Sie uns eine möglichst detaillierte Beschreibung sowie Screenshots, Requests/Antworten, damit wir Ihre Anfrage zeitnah und zielführend beantworten können.