Skip to main content

Settings Store

The Settings Store is a flexible system for storing configuration data with support for scoping, permissions, and validation. It allows plugins and the core system to store and retrieve arbitrary JSON data with fine-grained control over access and isolation.

It provides a robust, secure, and flexible system for managing configuration data in your Vendure application. Use it to store user preferences, plugin settings, feature flags, and any other settings data your application needs.

Info

The APIs in this guide were introduced in Vendure v3.4

Overview

The Settings Store provides:

  • Scoped Storage: Data can be scoped globally, per-user, per-channel, or with custom scope
  • Permission Control: Fields can require specific permissions to access
  • Validation: Custom validation functions for field values
  • GraphQL API: Admin API for reading and writing values
  • Service API: Programmatic access via the SettingsStoreService
  • Automatic Cleanup: Scheduled task to remove orphaned entries

Settings Store vs Custom Fields

Settings fields share some similarities to custom fields, but the important differences are:

  • Custom fields are attached to particular Vendure entities. Settings fields are not.
  • Defining a custom field adds a new column in the database, whereas settings fields do not.
  • Custom fields are reflected in corresponding GraphQL APIs and in the Dashboard UI.
  • Custom fields are statically typed, whereas settings fields store any kind of JSON-serializable data.

Settings fields are best suited to storing config-like values that are global in scope, or which configure data for a particular plugin.

Defining Settings Fields

Settings fields are defined in your Vendure configuration using the settingsStoreFields option:

Ts

Field Configuration Options

Each field supports the following configuration options:

OptionTypeDescription
namestringThe field name (combined with namespace to create full key)
scopeSettingsStoreScopeFunctionHow the field should be scoped (see scoping section)
readonlybooleanIf true, field cannot be modified via GraphQL API
requiresPermissionPermission | Permission[] | { read: Permission, write: Permission }Permissions required to access this field
validatefunctionCustom validation function for field values

Scoping

The Settings Store supports four built-in scoping strategies:

Ts

You can also create custom scope functions:

Ts

Permissions

You can control access to the Settings Store entry via the requiresPermission configuration property. If not specified, basic authentication is required for Admin API access.

Can be either:

  • A single permission or array of permissions (applies to both read and write)
  • An object with read and write properties for granular control. For custom permissions you can use a RwPermissionDefinition.

@example

Ts

GraphQL API

The Settings Store provides GraphQL queries and mutations in the Admin API:

Queries

Graphql

Mutations

Any kind of JSON-serializable data can be set as the value. For example: strings, numbers, arrays, or even deeply-nested objects and arrays.

Graphql
Note

By default, the Settings Store is not exposed in the Shop API. However, you can expose this functionality via a custom mutations & queries that internally use the SettingsStoreService (see next section).

Usage Examples

Ts

Using the SettingsStoreService

For programmatic access within plugins or services, use the SettingsStoreService:

Ts

SettingsStoreService Methods

MethodDescription
get<T>(ctx, key)Get a single value with optional type parameter
getMany(ctx, keys)Get multiple values efficiently in a single query
set<T>(ctx, key, value)Set a value with structured result feedback
setMany(ctx, values)Set multiple values with individual result feedback
getFieldDefinition(key)Get the field configuration for a key
Note

Prior to v3.4.2, ctx was the last argument to the above methods. However, since this is contrary to all other method usage which has ctx as the first argument, it was changed while deprecating (but still supporting) the former signature.

Orphaned Entries Cleanup

When field definitions are removed from your configuration, the corresponding database entries become "orphaned". The Settings Store includes an automatic cleanup system to handle this.

Manual Cleanup

You can also perform cleanup manually via the service:

Ts

Best Practices

  1. Use appropriate scoping: Choose the most restrictive scope that meets your needs
  2. Implement validation: Add validation for fields that accept user input
  3. Set permissions: UserequiresPermission for sensitive configuration data
  4. Mark sensitive fields readonly: Prevent GraphQL modification of critical settings
  5. Consider value size limits: Large values can impact performance

Examples

Plugin Integration

Ts

Frontend usage

Tsx
Was this chapter helpful?
Report Issue
Edited Feb 23, 2026ยทEdit this page