Legacy credentials and migration

Older PushFire projects authenticated every API call with a single project token. During the API keys upgrade that credential is preserved as a Legacy key so existing backends and SDKs keep working without an emergency cutover.

Legacy authentication does not use the pf_pk_ / pf_sk_ / pf_rk_ prefix model and does not apply the Public versus Secret scope split. It behaves like the previous “one token for everything” model and is deprecated.

Migrated projects keep the Legacy key and also receive a Public key and a Secret key with new material. All three can exist at the same time:

• Legacy: Old Bearer value. Keeps current integrations alive.
• Public (pf_pk_): New. Put this in SDKs and apps that only need identity APIs.
• Secret (pf_sk_): New. Put this on servers that send messages or start workflows.

1. Copy the Public key into your mobile/web SDK configuration. Deploy and verify device/subscriber calls.
2. Copy the Secret key into your backend secret store. Point send-batch and workflow calls at it. Deploy and verify.
3. Monitor production until you are confident no service still depends on the Legacy Bearer.
4. In Developers → API keys, revoke the Legacy key. Old Bearer requests will fail after revoke.

Do not revoke Legacy on day one. Coexistence exists so you can validate Public and Secret first.

Only Public, Secret, and any Restricted keys remain. Rotate platform keys when you need to cut old Secret material. Create Restricted keys for least-privilege integrations.

Continue with Public and Secret keys and the API Reference.