Skip to content

Docs

Environments and public keys

On this page

Each app has two environments, development and production, and a separate public key for each. The public key identifies the app to a client. It is not a server secret. A server API key is a different secret, created in workspace settings, and it can act on every app. Each call names the app and the environment.

How it works

Both keys are created with the app. Each key is ntf_pub_ plus 32 random lowercase characters, and each key is unique. The app’s current environment decides which key is active. New apps start in development.

The keys screen shows the start of each public key and hides the rest. Copy opens a white warning under the keys: the key identifies the app, it cannot send, and it belongs only in the SDK configuration. A developer, admin, or the owner can switch the active environment between development and production, and can reset a key. Resetting shows that new key in full once. The next visit hides it again. React Native, Flutter, and Other stay in development until Android, iOS, or both is configured. Choosing production then shows “Configure Android, iOS, or both before production.” and does not switch. A viewer can see the keys. Resetting a key replaces only that environment’s key and leaves the other one in place. Older clients still holding the previous key can no longer identify themselves with it.

The same screen shows notification delivery configuration. Android is managed by Notifiable from the package name. The workspace Apple connection is shown there as activated, with the mark on white. See configuration opens the team and key. The signing key is not shown. A missing Apple connection, package name, or bundle ID is marked in red, and the control on that row is the action to finish it. While that preparation is running, the page says Android is being prepared. Expo is managed and needs no secret. Web is managed by Notifiable and shows the public key the browser SDK needs. The private key is not returned. iOS uses the workspace Apple connection. Connect Apple Developer once. Later apps in that workspace only need a bundle ID. A secret saved on an app before this change still sends for that app and environment. Development Apple delivery uses Apple’s sandbox. Production uses Apple’s production host. A public key still cannot send.

Notifiable keeps a fleet of its own Google projects for Android, 30 apps each. A full project opens the next one. That fleet is Notifiable’s infrastructure. The customer never connects a Google project. If the fleet is not configured, the app is still created and Android is marked not ready.

Server API keys live on workspace settings, under API keys. Documentation opens the API reference. A developer, admin, or the owner can create one. The form asks for a name, an expiration (never, 30 days, 90 days, or 1 year), a request limit (unlimited, 1,000, or 10,000), and when that limit resets (not at all, daily, or monthly). It does not ask for an environment. The full ntf_key_ secret is shown once. The list can be searched by name or prefix. It shows the name, a prefix, when it expires, when it was last used, how many requests it has made in the current period, and the limit. Revoke deletes the selected keys in this workspace. A viewer can see the list and cannot create or revoke. An expired key and a revoked key are rejected. A key that is over its limit is rejected until the period resets. A key created before this change belongs to the workspace of the app it was created for, and it can reach every app in that workspace.