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.
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:
Field Configuration Options
Each field supports the following configuration options:
| Option | Type | Description |
|---|---|---|
name | string | The field name (combined with namespace to create full key) |
scope | SettingsStoreScopeFunction | How the field should be scoped (see scoping section) |
readonly | boolean | If true, field cannot be modified via GraphQL API |
requiresPermission | Permission | Permission[] | { read: Permission, write: Permission } | Permissions required to access this field |
validate | function | Custom validation function for field values |
Scoping
The Settings Store supports four built-in scoping strategies:
You can also create custom scope functions:
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
readandwriteproperties for granular control. For custom permissions you can use a RwPermissionDefinition.
@example
GraphQL API
The Settings Store provides GraphQL queries and mutations in the Admin API:
Queries
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.
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
Using the SettingsStoreService
For programmatic access within plugins or services, use the SettingsStoreService:
SettingsStoreService Methods
| Method | Description |
|---|---|
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 |
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:
Best Practices
- Use appropriate scoping: Choose the most restrictive scope that meets your needs
- Implement validation: Add validation for fields that accept user input
- Set permissions: Use
requiresPermissionfor sensitive configuration data - Mark sensitive fields readonly: Prevent GraphQL modification of critical settings
- Consider value size limits: Large values can impact performance