Accessing the history
Columns
Each row corresponds to a single field change.
| Column | Description |
|---|---|
| Timestamp | Date and time of the change (format YYYY-MM-DD HH:mm:ss). |
| Key | The setting key that changed, in dotted notation (for example usage_limits.daily_limit_cents, webhook.enabled, operating_hours.open_time). |
| Old Value | The value before the change. |
| New Value | The value after the change. |
| Actor | The identifier of the user or service that made the change. |
| Revision | Monotonically increasing revision number assigned at save time, shown as a badge. |
Reading secrets
Secret fields (password, private key, webhook signing secret) are never stored in clear text in the history. When a secret is changed, both Old Value and New Value show
•••• so the fact of the change is auditable without exposing the secret itself.
Empty state
If no changes have been recorded yet, the tab shows No changes recorded yet. The first save on the Settings tab populates the history.
How entries are created
Every time you click Save on the Settings tab:
- The plugin compares the form values against the last saved state.
- It sends only the fields that changed.
- Each changed field becomes a separate entry in the history, sharing the same revision number.
Tips
- Keep the History tab handy when investigating issues. A regression that started at a specific time often lines up with a setting change visible here.
- When coordinating a change with a third party (for example a new JD environment), note the revision number — it is a stable reference to the exact configuration live at that moment.