Secrets

Secrets lets an Admin store a credential once (an API key, token, or password) and reference it by name from an Enrichment or Cron script, instead of hardcoding it into the script's own source. Available on every plan.

Why you'd use this

An Enrichment or Cron script that calls an external service usually needs a credential to authenticate with it. Pasting that value directly into the script's code means it's permanently visible in the editor, in every past version in history, and in every old Test result. Secrets exist so the script only ever references a name, and the value itself lives encrypted, separately, shown exactly once.

Creating a secret

Settings → Secrets: a Name (must be a valid Python identifier — letters, digits, underscores, can't start with a digit) and a Value, masked while typing.

Once created, the catalog shows only the name and a copyable access snippet — the value itself is never shown again, anywhere, not even to an Admin:

Using it from a script

def enrich(event):    api_key = secrets.get("GEOIP_API_KEY")    if not api_key:        return event  # not set (yet) -- degrade gracefully, don't raise    # ... call the external API using api_key ...    return event

secrets.get(name, default=None) is the only way to read a value — it is deliberately not a plain dict, so a script can't do something like list(secrets) and dump every credential at once.

Both the Enrichments and Cron script editors have an "Available secrets" info button next to the code field, listing every secret's name (never its value) for quick copy-paste:

Rotating or removing a secret

Rotate (on that secret's row) replaces the value in place — the old value is not recoverable afterward. Delete removes it entirely; any script still calling secrets.get() for that name afterward just gets back None (or whatever default was passed), the same as a name that was never created.

What to know

• A secret's value is never shown again after creation — stricter than API Keys' reveal-once pattern, at the customer's own explicit request when this feature was built. There is no "reveal" action anywhere for a Secret.
• If a script's own code happens to print, return, or raise a resolved secret value, that value is automatically redacted (shown as ***) before it ever reaches a Test result or any other output — a debugging mistake can't leak it through the UI.
• Losing or rotating the installation's underlying encryption key strands every already-stored secret permanently, with no recovery path. This is an infrastructure-level concern for whoever manages the deploy, not something to worry about in day-to-day use — but worth knowing if a secret a script depends on suddenly stops resolving after an infrastructure change.