System Settings Reference
Every predefined system setting explained — purpose, example value, when to change it, and how to handle secure tokens.
System settings are the cluster's central configuration store: predefined keys that tune cluster behavior, plus your own custom keys for integration tokens and environment parameters. This reference covers every predefined key, when a change is justified, and how to work with secure values. For the conceptual overview, see System Settings.
Predefined Keys
These keys exist on every cluster. Changing one alters cluster behavior immediately — no deploy needed.
| Key | Purpose | Example | When to change it |
|---|---|---|---|
timezone |
Default timezone for executing date type blocks. |
Europe/Amsterdam |
When your users and data live in a different timezone than the cluster default. |
thousand_separator |
Separator for formatting thousands in numbers. | . (10.000) or , (10,000) |
To match your locale's number display. |
decimal_separator |
Separator for formatting decimals in numbers. | , (9,99) or . (9.99) |
To match your locale's number display — pair it with thousand_separator. |
language_user_enabled |
Uses the user's profile to determine their language. | true |
When users have mixed languages and you store a preference per user. |
language_query_enabled |
Uses the query string to determine the user's language. | true |
When you pass ?lang= (or similar) in shared links. |
language_browser_enabled |
Uses the browser's supported language to determine the user's language. | true |
Usually left on; turn off to force language_default for everyone. |
language_default |
Fallback language when no preference can be determined. | nl or en |
Set once, at cluster setup, to your primary audience's language. |
input_datetime_format |
Date format used in datetime inputs. | YYYY-MM-DD HH:mm:ss |
When users expect a different entry format (e.g. US month-first). |
input_date_format |
Date format used in date inputs. | YYYY-MM-DD |
When users expect a different entry format. |
date_default_format |
Default format for rendering dates in the UI. | YYYY-MM-DD HH:mm:ss |
To change how dates appear throughout your pages. |
default_divide_by |
Default divisor for pricing inputs. |
100 (store cents) |
Set to 100 when prices are entered as whole euros but stored as cents — prevents rounding errors. |
email_default_from |
Default from address for outgoing emails. |
noreply@yourdomain.com |
Required before any mail leaves the cluster — see the email setup below. |
messagebird_originator |
Default originator name for MessageBird SMS used in two-factor authentication. | YourApp |
Only when you use SMS-based 2FA via MessageBird. |
postmark_token |
Default Postmark server token for sending emails (password resets, notifications). | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
Once per cluster, before sending email. Store it as a secure value — it is a secret. |
When to Modify Settings
Change a predefined key only when the default actively hurts. Legitimate reasons:
- Localization — timezone, separators, languages, and date formats should match your audience (once, at setup).
- Integrations — tokens and originators for email/SMS must exist before the features that use them work.
- Environment differences — use custom keys for values that differ between development and production (API hosts, webhook URLs), so the same blueprint works on both by reading the key.
Avoid using settings as a general data store: documents belong in a storage, configuration of behavior belongs in settings.
Secure vs Non-Secure Values
A value marked secure stays concealed: it is not shown in overviews, in the Studio, or in blueprint data. Every read of a secured key is written to the audit log, so you can see exactly who accessed which token and revoke accordingly.
| Non-secure | Secure | |
|---|---|---|
| Visible in Studio / overviews | Yes | No — concealed everywhere |
| Readable by blueprints | Yes | Yes — the value is injected at execution time |
| Reads logged in audit log | No | Yes |
| Use for | Formats, locales, feature flags, public hosts | API tokens, passwords, signing secrets (e.g. postmark_token) |
Control who can manage settings at all with the setting_manage_users-family permissions — see User Access Management.
Email Configuration Example
A complete working email setup needs two keys:
postmark_token— create a server token in Postmark, add it as a secure system setting.email_default_from— set it to an address on your verified Postmark sender domain, e.g.noreply@yourdomain.com.
From that point, password resets and any email-sending blocks work without further configuration. For SMS-based two-factor authentication, also set messagebird_originator to your sender name.
Custom Keys & Token Management
You can add your own keys. Conventions that keep them manageable:
- Naming — prefix by integration:
stripe_secret_key,slack_webhook_url. Keep lowercase with underscores. - Secrets — always mark tokens secure at creation time; rotating means editing the value in one place, and every blueprint picks it up on the next run.
- Custom vs predefined — predefined keys tune the cluster itself; custom keys hold your integration parameters. Do not overload a predefined key with an unrelated value.
Reading Settings in Blueprints
Use the get system setting block to read a key into a flow — pick a predefined key statically or provide the key name dynamically as a value. The block returns the current value at execution time, including decrypted secure values (never logged in plain text by the platform).
Typical pattern: read stripe_secret_key at the start of a payment flow, then pass it into the request blocks — one setting to rotate, zero blueprint edits.
