Crossdeck University
Docs Start free
Watch — the right key in the right place, every time Film in production
0:00 / 0:00
Reference · Lesson 4 of 4

API keys & authentication

Two kinds of key, two jobs. A publishable key identifies your app and is safe to ship anywhere; a secret key is a credential for your server. Knowing which goes where is most of integration security.

3 min Reference

When you're done: you use the right key in the right place — and never leak the one that matters.

1 What this is & why it matters

The most common setup mistake is a key in the wrong place

A surprising share of integration security comes down to one thing: using the correct key in the correct place. Crossdeck has exactly two — a publishable key and a secret key — and the difference between them is the difference between "safe in a browser" and "treat like a database password." Mix them up and you've either broken your app or leaked a credential.

2 The two keys

Publishable to identify, secret to authenticate

  • Publishable key (cd_pub_…) — designed to ship in client code. It appears in browser network tabs, inside compiled mobile binaries, anywhere clients run, and that's intentional and safe. It proves "this request is from Crossdeck app X" — it's an app identifier, not a credential.
  • Secret key (cd_sk_…) — a credential. It authenticates your server to Crossdeck and unlocks the operations that must never reach a client: manual entitlement grants, audit-log reads, and bulk operations like the migration import. Treat it like a database password — server-side only, never in a repo, never in a bundle.
3 How it works, piece by piece

The prefix tells you everything

The prefix is the contract: cd_pub_ is public-by-design, cd_sk_ is secret-by-design. A few rules follow from that:

  • Test mode and live mode have their own keys, so a test key physically can't touch live data — the partner to the environment isolation you just saw.
  • Web keys carry origin allowlists, so a publishable key only works from your own domains — a copied one is useless elsewhere.
  • Keys rotate and revoke without downtime. Issue a new one, move traffic over, retire the old — no flash cut, so a suspected leak is a calm rotation, not an outage.

The rule that prevents most incidents: never put a cd_sk_ key in client code. The SDK init() even enforces the inverse — it rejects anything that isn't a cd_pub_ key — so a secret key in your front end fails loudly instead of leaking quietly.

4 The result

Right key, right place

Publishable keys ride along in your apps doing their one safe job; secret keys stay on your servers guarding the privileged operations. If a key is ever exposed, you rotate it without downtime. That's the whole discipline — and the end of the Reference.

app.cross-deck.com · api keys
cd_pub_ in client · cd_sk_ on server

App identifier in the browser, credential on the backend, test and live kept apart — and any key rotatable without an outage.

Read the API keys reference in the docs

Publishable (cd_pub_) = app identifier, safe in client code. Secret (cd_sk_) = credential, server-only (grants, audit reads, bulk ops) — treat like a database password. Test and live have separate keys; web keys carry origin allowlists; everything rotates without downtime. Never put a cd_sk_ in client code — init() rejects non-cd_pub_ keys.