​

Environments

Each Notifizz organisation has multiple environments — typically dev and prod, plus optional staging or per-team variants. Each environment owns its own copy of every secret and its own event traffic. Sharing keys across environments is the most common cause of “weird” failures.

​

TL;DR

• Every environment has its own SDK Secret, Auth Secret, Front API Key, Webhook Signing Secret.
• Implementation and Review campaigns never run on production; Live runs on every environment — but only a production key produces a real delivery.
• Rotate by generating the new key alongside the old, deploy, retire the old.
• Don’t share keys across environments — even for internal tooling.

​

What’s per-environment

Every secret and every campaign-runtime decision is per-environment: The campaign object itself is shared across environments; the status check is per-env. An Implementation campaign exists in both dev and prod’s view of the campaign list, but only runs on dev (see campaigns for the runnable filter).

​

Typical environment layout

The Implementation / Review gate is the explicit guardrail: a campaign staged for you to verify can’t accidentally fire on prod traffic. See send scope for what each status is allowed to deliver.

​

Borrowing enrichers from another environment

Standing up a fresh environment usually means re-declaring every enricher before a single campaign can be tested — even though the declarations are identical to the ones next door. A non-production environment can instead nominate a source environment to borrow from, in Settings → Environments. The rule is narrow on purpose: an enricher is borrowed only when the calling environment doesn’t declare it itself. A local declaration always wins, so borrowing never shadows what you have deliberately set up. What follows the declaration matters more than the declaration itself. Everything used to exercise a borrowed enricher — the signing secret, the connector’s API key, the cache key — is read from the source environment, not the borrower. A webhook borrowed from staging expects staging’s signature, so that is the one Notifizz sends. Responses carry the environment they were borrowed from, so a test trace can say where the data actually came from. Two consequences worth internalising before you enable it:

• A borrowed enricher calls the source environment’s endpoint with the source’s credentials. If you borrow from production, your dev campaign is hitting production’s data. That may be exactly what you want for a realistic rehearsal — it is never something to enable absent-mindedly.
• Removing an enricher from the source environment breaks every borrower. The error names both environments, so the missing declaration is not a mystery.

​

When to rotate keys

​

Rotation flow

The dashboard exposes a rotation flow per secret with an overlap window: For emergencies (suspected leak), the “rotate now, no grace period” path skips the overlap window. Use it when the cost of “any service might still be using the old key” is lower than the cost of “the leaked key remains valid”.

​

Test in Dev before Live

The standard flow for any campaign change:

1. Edit on dev. Promote Editing → Dev.
2. Fire test events from your dev backend. Verify delivery in dev’s delivery history.
3. Fix implementation tasks (missing properties, broken orchestrator code, …) until clean.
4. Promote Dev → Live. The campaign now also fires on prod traffic.

The implementation-task system is what makes this safe — the dashboard surfaces problems before they hit prod.

​

CI integration

In CI environments, use a dedicated key per pipeline:

• A read-only key for “verify a notification path works” tests against dev.
• A separate prod-tracking key only for the build that actually emits to prod (typically a release job).

Don’t share keys between developer machines and CI. Generating one CI key per pipeline gives you per-pipeline audit trails and lets you revoke access without rotating dev keys.

​

FAQ

​

See also