API Keys and Security

How a key is generated

Keys are minted on our servers with a cryptographically secure random generator. A key is ph_live_<prefix>_<secret>: an 8-character public prefix that identifies the key in your workspace and in our logs, and a 256-bit secret. The secret is not derived from your account, your name or the time of issue, and two keys never collide.

How a key is stored

We never store the key. What is saved is an HMAC-SHA-256 digest of it under a server-side pepper that lives only in our runtime environment, alongside the public prefix. A database dump on its own therefore yields nothing usable, and neither our staff nor our support tooling can read your key back to you.

The clear text is shown exactly once, in the response to the request that created it. If you lose it, there is no recovery path: revoke that key and create another.

What a key can reach

A key authenticates as your organisation and nothing else. Every response is filtered again by your active licence -- publish window, sports, leagues and entitlements are re-checked per record -- so a key cannot read a pick outside the licence even by guessing its identifier. Keys reach the licensed /api/v1 endpoints only; they cannot reach the administration or internal surfaces, which use separate credentials.

Expiry, limits and rotation

Expiry

A key expires one year after it is issued unless a shorter lifetime was set for you. An expired key returns 401; it is not renewed automatically.

Active limit

Five active keys per organisation. That is deliberately enough to overlap two during a rotation and not enough to lose track of one.

Rotation

Create the replacement first, deploy it, confirm traffic on the new prefix in your workspace, then revoke the old key. Nothing is interrupted, because both are live in between.

Last used

Each key shows when it was last used, so an unused key is easy to identify before you revoke it.

Revoking a key

An account owner can revoke any of the organisation’s keys from the Developer page, and it stops working immediately -- no support ticket, no waiting. Every issue and revocation is recorded in our audit trail against the user who performed it.

If a key may have leaked, revoke it first and investigate afterwards. Creating a replacement takes seconds.

Handling a key in your own stack

• Keep the key on a server. It must never appear in browser code, a mobile bundle, a client-side environment variable (anything prefixed NEXT_PUBLIC_, VITE_ or equivalent is shipped to the browser), or a URL query string.
• Read it from an environment variable or a secret manager. Do not commit it to a repository, paste it into a ticket or a chat, or bake it into a container image.
• Send it only in the Authorization header, over HTTPS.
• Keep it out of your logs: log the public prefix if you need to identify which key made a call.
• Use one key per system, not one key everywhere. When something needs rotating you then rotate one integration, not all of them.

# .env on your server, never in a browser bundle
POWERHOUSE_API_KEY=ph_live_…

# Node, server-side only
const apiKey = process.env.POWERHOUSE_API_KEY;
if (!apiKey) throw new Error("POWERHOUSE_API_KEY is required");

await fetch("https://www.powerhousesportsdata.com/api/v1/picks", {
  headers: { Authorization: `Bearer ${apiKey}` },
});