Authentication overview
Cheggout uses two authentication schemes, chosen by product line, plus a token layer that sits on top of both.
| Scheme | Used by | How you prove identity |
|---|---|---|
| Signed envelope | Rewards Center, Bank & SDK APIs | RSA signature over the request payload |
| API key | Deals Store | A key and secret in the Authorization header |
Both are server-to-server only and both additionally require your egress IPs to be whitelisted.
Signing keys and API secrets belong on your backend. A mobile app or web page authenticates with a short-lived token that your backend obtained on the user's behalf.
Which one do I use?
If you integrate both product lines you will implement both. They are independent — an API key does not work on the Rewards Center, and a signature does not work on the Deals Store.
The split is along product lines: the Deals Store uses an AppKey header, and the Rewards Center and Bank APIs use signed envelopes. Use whichever scheme the endpoint's reference page specifies.
The layers
Layer 1 is infrastructure: HTTPS everywhere, and Cheggout only accepts server calls from IPs you registered during onboarding.
Layer 2 proves which publisher is calling. Either a signature made with your private key, or your API key and secret.
Layer 3 scopes the request. Layer 2 credentials are used to mint tokens; the tokens are what your per-user, per-request calls carry.
Token types
Three distinct tokens exist. Confusing them is the most common integration error.
| Token | Minted by | Scope | Used for |
|---|---|---|---|
| Reference token | getSecuredReferenceToken | Your channel, not a user | Creating scratch cards (GetReward) |
| User token | GetAuthToken | One specific user | Revealing rewards, listing reward history |
| Session ID | GenerateSessionInfoV2 | One user's SDK/PWA session | Launching the SDK or a hosted microsite |
The reference token carries no user identity — the user is identified by the virtualId in the
request body. That is why it can be fetched once per hour and shared across all your users. The
user token is the opposite: it is the user's identity, and reveal endpoints reject a reference
token.
Full lifetimes and refresh guidance: Tokens.
Single sign-on
For SDK and hosted experiences, the customer must never see a Cheggout login.
Your authentication is the trust anchor. Cheggout trusts the signed assertion from your backend that
this virtualId is a real, authenticated customer of yours — so the integrity of your signing key
is the integrity of the whole flow.
Verifying Cheggout's responses
Signed endpoints return a signed response: CHANNELID: "CHEGGOUT", a SIGN, and a BDATA payload.
Verify SIGN with Cheggout's public key before trusting the payload.
Success responses carry a signature. Some failure responses are returned as plain unsigned JSON. Your verification code must handle an unsigned error body without crashing — check for the failure shape before attempting verification. See Error codes.
Security requirements
- HTTPS for all communication, both directions.
SHA256withRSAfor signing, with signatures Base64-encoded.- Private keys in a secret manager, never in source control, app packages or JavaScript.
- Rotate keys if a key is ever exposed — including exposure through an app binary.
- Tokens are bearer credentials. Anyone holding one can act as that scope. Keep them short-lived, out of URLs, and out of logs.
- Minimise PII. Only your pseudonymous
virtualIdcrosses the boundary.
More: Security best practices.
Next
- The signed envelope — exact construction, with code.
- Key generation — producing your key pair.
- Tokens — lifetimes and refresh.
- API key authentication — the Deals Store scheme.