---
title: "System Settings Reference · RUAL Documentation"
description: "Every system setting, its type and what changing it affects."
canonical: https://docs.rual.nl/blueprints/system-settings-reference
language: en
---

# 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](https://docs.rual.nl/blueprints/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](https://messagebird.com/) SMS used in two-factor authentication. | `YourApp` | Only when you use SMS-based 2FA via MessageBird. |
| `postmark_token` | Default [Postmark server token](https://postmarkapp.com/) 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](https://docs.rual.nl/blueprints/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](https://docs.rual.nl/cluster/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.

### Next Steps