Skip to main content

​
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.
  • Dev campaigns run on dev only; Live runs on every environment.
  • 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:
SurfacePer-environment?
SDK Secretyes
Auth Secretyes
Front API Keyyes
Webhook Signing Secretyes
Campaign status (Live / Dev / …)resolved per env at instance creation
Connector source verificationSecretper source, scoped to its environment
Enricher URLyes (you can declare different URLs per env)
Regionper environment (the env determines the API hostname)
The campaign object itself is shared across environments; the status check is per-env. A Dev 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

EnvironmentPurposeCampaign statuses that run
devLocal development, iterationEditing, Dev, Live, Offline (per the runnable filter)
staging (optional)Pre-prod validationSame as dev, but with prod-like data volumes
prodCustomer trafficLive, plus Editing and Offline at instance creation (downstream behaviour varies — consult source)
The Dev gate is the explicit guardrail: orchestrators staged for review can’t accidentally fire on prod traffic.

​
When to rotate keys

TriggerWhat to rotate
Engineer leaves the companyAll secrets they had access to.
Suspicion of leakThe compromised secret immediately, with the dashboard’s emergency rotation flow.
Routine policy (every 6–12 months)All secrets, environment by environment.
Front API Key visible in a leaked git repoThe Front API Key is public-by-design (embedded in your frontend) — rotate only if you’re using none mode in production (which you shouldn’t).

​
Rotation flow

The dashboard exposes a rotation flow per secret with an overlap window:
1

Generate the new key

Dashboard → Environment → API Keys → “Rotate”. A new key is generated; the old key remains valid for the overlap window (configurable, typically 24h).
2

Update your services

Push the new key to your secret manager / env vars. Redeploy.
3

Wait the overlap window

Both keys work during this period. Existing in-flight requests using the old key complete; new requests pick up the new key.
4

Retire the old key

Click “Retire previous”. The old key is invalidated immediately; any service still using it gets 403 auth/invalid-authorization on the next call.
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 dev tasks (missing properties, broken orchestrator code, …) until clean.
  4. Promote Dev → Live. The campaign now also fires on prod traffic.
The dev-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

No. Each environment has its own pair. Sharing causes hard-to-debug cross-traffic — your dev test events end up in prod’s queue, or vice versa. Treat keys as environment-scoped from day one.
Set its status to Dev and never promote it. The runnable filter explicitly excludes Dev from production environments — your dev iteration stays out of prod traffic.
One per pipeline. CI keys are usually scoped to the dev environment for test/integration work; only the release job uses a prod key, and that key only ever touches prod.
Within seconds — the backend reads keys per request, no caching beyond a short TTL on the resolution. If your SDK throws 401 minutes after rotation, your service is still using the old key (env var not reloaded, secret manager not refetched).
Archive all its campaigns first. Then revoke its keys (rotate to nothing, decline the new generation). Then delete from the dashboard. In-flight workflow instances complete or fail naturally; no live traffic continues post-delete.
Either works. One shared dev is simpler operationally; one-per-developer is cleaner if you have many engineers. The dashboard supports both — environments are cheap.

​
See also

Keys and environments reference

The five secrets and where each goes.

Campaigns

Statuses, runnable filter, versioning.

Delivery history & stats

Where to verify a delivery worked.

Troubleshooting

Cross-cutting failure modes.