Skip to main content
Keep API keys on your backend. Never include a secret in browser code, a Roblox client script, a public repository, screenshots, or logs.

​
PID and API keys

A PID identifies a verification integration. An API key authenticates requests from your backend. A PID does not replace the secret key in the Authorization header.
Send users the verification URL returned by Dock. Do not add your secret key to a verification link.

​
Key lists and secret visibility

Your key list can show a key’s name, prefix, status, scope, and usage even when its full secret cannot be revealed. An unavailable secret does not mean that the key was deleted or replaced. Listing a key, revealing its secret, and authenticating a request are separate checks. A successful list response does not prove that an integration can authenticate. Check the integration with the credential it already stores before deciding to replace a key. If a secret is unavailable, keep a working credential in its existing secure storage. Contact support with the key’s non-secret identifier or prefix. Never send the full key.

​
Check authentication

The v2 key-information endpoint is GET /v2/key. Call it from your backend with the same Bearer key your integration uses. Check the HTTP status and the response before testing account lookups.
A rejected key needs investigation. Changing a PID or guildId cannot make a revoked, disabled, or invalid credential valid.

​
Replace an exposed key

If a key is exposed, revoke it and replace it in each application that uses it. Confirm the replacement works, then remove the exposed value from your configuration and logs. Do not create extra keys to bypass quotas or access restrictions.