API key authentication

The Deals Store APIs — catalogue, inventory, coupon delivery and user coupons — authenticate with an API key pair in a header, rather than the RSA-signed envelope used elsewhere.

Why two schemes

The Deals Store moved from RSA signing to an API key in version 1.3 of its contract. The Rewards Center and Bank APIs still use the signed envelope. Use whichever the endpoint's reference page specifies.

Credentials

Credential	Issued by	Where it lives
`APP_KEY`	Cheggout	Your backend, in a secret manager
`SEC_KEY`	Cheggout	Your backend, in a secret manager
`CHANNELID`	Cheggout	Your backend (an identifier, not a secret)

Both keys are issued during onboarding and should be rotated periodically.

Server-side only

These are static credentials with no user scope and no expiry. Anyone holding them can read your entire catalogue and issue coupons against any virtualId. They must never reach a mobile app, a web page, or a repository.

Headers

POST /api/fetchCouponCode HTTP/1.1
Host: hotdeals.cheggout.com
Content-Type: application/json
X-CHANNELID: YOURCHANNEL
Authorization: CheggoutAppKey <APP_KEY>:<SEC_KEY>

Header	Required	Notes
`Authorization`	Yes	Literal prefix `CheggoutAppKey` , then `APP_KEY`, a colon, and `SEC_KEY`.
`X-CHANNELID`	Yes on most endpoints	Your channel identifier.
`Content-Type`	On POST	`application/json`

The Authorization value is matched exactly. Extra whitespace, a different prefix, or reordering around the colon will fail authentication.

Second layer: IP whitelisting

API-key authentication is intended to be paired with IP whitelisting — Cheggout registers your server egress IPs during onboarding, and calls should originate from them.

TBD Confirm enforcement with Cheggout. Do not treat the IP layer as your only control: protect the keys as if they were the sole credential, because in practice they may be.

Example

curl -X POST https://hotdeals.cheggout.com/api/getUserCoupons \
  -H "Content-Type: application/json" \
  -H "X-CHANNELID: YOURCHANNEL" \
  -H "Authorization: CheggoutAppKey REPLACE_APP_KEY:REPLACE_SEC_KEY" \
  -d '{
        "offerId": "517",
        "virtualId": "pub_8f14e45fceea167a",
        "channelName": "YOURCHANNEL"
      }'

Authentication errors

`status`	`errorCode`	Meaning
`401`	`UNAUTHORIZED`	Missing, malformed or incorrect `Authorization` header
`403`	`FORBIDDEN`	Request blocked — calling IP not whitelisted

Status codes arrive in the body

Deals Store responses carry the status inside the JSON body as a status field. Check the body value rather than relying only on the HTTP status line. See API conventions and Error codes.

Operational guidance

Store both values in a secret manager, injected at runtime.
Never log the header. Redact Authorization in access logs and error reports.
Use different keys per environment. UAT keys must not work in production.
Rotate on schedule and immediately on any suspected exposure.
Scope access narrowly — only the service that calls Cheggout should be able to read the keys.

TBD No self-service rotation exists. Rotation is coordinated with Cheggout; ask for the overlap window so you can swap without downtime.

Credentials​

Headers​

Second layer: IP whitelisting​

Example​

Authentication errors​

Operational guidance​

Next​