Get and manage your PrizePicks API key.

Create a key in your workspace

• Create an account or sign in to prizepicksapi.com.
• Open API keys in the workspace and give the key a recognizable name, such as a project and environment.
• Copy the token when it is displayed. It is shown once, so store it in a server-side secret manager.
• Make one small authenticated request and check both the response and source health.

This token authenticates requests to prizepicksapi.com. It is not a PrizePicks consumer-account credential, and you should not paste a betting-account password or session cookie into this service. The product is independent of PrizePicks; creating a key here does not grant official platform account access.

Use the Authorization header

curl "https://prizepicksapi.com/api/v1/projections?league=NBA&limit=5" \
  -H "Authorization: Bearer $PRIZEPICKS_API_KEY"

The example reads the token from an environment variable. Replace the variable’s value in your runtime configuration, not in a committed source file. The header must contain the Bearer scheme followed by the actual token. Sending a token in a query string is unsupported and risks putting it into URL logs, browser history, analytics, and shared screenshots.

For a browser application, call your own backend and let that backend authenticate with the data API. A key embedded in client-side JavaScript can be extracted by a visitor even if the interface never displays it. Mobile applications have the same issue when a reusable secret is bundled into the app. Use a server boundary and apply your own user authorization before returning data.

Understand what the workspace stores

The service stores a cryptographic hash of the token for authentication. Key listings show identifiers, a prefix, name, creation time, last-used time, and revocation state; they do not reveal the original token or its stored hash. If you lose the token, create another key and revoke the old one rather than expecting a reveal-existing-secret action.

An account may have up to five active keys. Separate keys can help distinguish development, staging, and production credentials, but they do not create separate plans. Monthly usage and minute limits are enforced at the account level. Revoking a token blocks future authentication with it; revocation does not erase the account’s recorded usage.

Rotate a token with a controlled handoff

• Create the replacement key before revoking the active one, provided you have a free key slot.
• Update your deployed service’s secret configuration and restart or redeploy the processes that read it.
• Verify a successful request with the new key from the actual application environment.
• Revoke the previous key in the workspace. Confirm a request using it now receives 401.
• Remove old copies from CI variables, local secret files, and any other runtime that no longer needs them.

If a token is exposed, prioritize revocation and replacement. Renaming the key or deleting it from your local file does not invalidate a leaked copy. Avoid printing Authorization headers in request traces. When troubleshooting, log the response status and error code rather than the token itself.

Separate authentication from quotas and data freshness

A working key does not establish the freshness or completeness of the data. The API deliberately returns source-health metadata separately from authentication results. Keep that distinction in monitoring: an authorization failure, an exhausted allowance, and an aging collection should produce different operational actions.

PrizePicks API is an independent data service. It is not affiliated with or endorsed by PrizePicks. Observations, completeness, and freshness are separate claims; consult source status before relying on a stored line.