Environments & endpoints

Cheggout runs two environments. Build and certify against UAT, then switch hosts for production — request and response contracts are identical.

Host reference

Hosts are grouped by product line. Each API reference page repeats its own hosts; this is the consolidated view.

Rewards Center API — headless scratch cards

Environment	Base URL
Production	https://rewardscenter.cheggout.com/api/
UAT	https://rewardscenter-uat.cheggout.com/api/

Endpoints: getSecuredReferenceToken, GetReward, GetAuthToken, FetchRewardInfo, GetAllScratchCardsByUserId.

Deals Store API — headless coupons

Environment	Base URL
Production	https://hotdeals.cheggout.com/api/
UAT / Stage	https://onerupee-store-api-stage.azurewebsites.net/api/

Endpoints: getCatalogue, getCatalogueInventory, fetchCouponCode, getUserCoupons.

UAT has no vanity domain

The Deals Store UAT host is a raw cloud hostname rather than a cheggout.com domain. Keep it in configuration, not hardcoded — it is expected to move behind a branded UAT domain.

Bank & SDK server APIs

Environment	Base URL
Production	https://bankapi.cheggout.com/api/
UAT	https://bankapi-uat.cheggout.com/api/

Endpoints: GenerateSessionInfoV2, getSecuredReferenceToken, GetScratchCardForBank.

Web widget assets

Environment	Script
UAT	https://chegwidgetuat.z29.web.core.windows.net/cheggout-widget.iife.js?channelName={channelName}
Production	TBD not yet published

No production widget URL yet

The only widget artifact currently available is served from a UAT host and is built for UAT backends. Do not point production traffic at it. See Open Items — a production build and URL are pending.

Hosted experience (PWA)

Launch URLs are per-experience and issued during onboarding. See Hosted launch URLs for the parameter contract.

Endpoint-to-host quick reference

Endpoint	Product line	Host family
getSecuredReferenceToken	Rewards Center	rewardscenter.*
GetReward	Rewards Center	rewardscenter.*
GetAuthToken	Rewards Center	rewardscenter.*
FetchRewardInfo	Rewards Center	rewardscenter.*
GetAllScratchCardsByUserId	Rewards Center	rewardscenter.*
getCatalogue	Deals Store	hotdeals.*
getCatalogueInventory	Deals Store	hotdeals.*
fetchCouponCode	Deals Store	hotdeals.*
getUserCoupons	Deals Store	hotdeals.*
GenerateSessionInfoV2	Bank / SDK	bankapi.*
getSecuredReferenceToken	Bank / SDK	bankapi.*
GetScratchCardForBank	Bank / SDK	bankapi.*

getSecuredReferenceToken is published on both host families

It appears twice in the table above, and that is not a mistake. The same endpoint name is documented on the Rewards Center hosts and on the Bank / SDK hosts. Use the one belonging to the product line you are integrating, and confirm your host at onboarding.

TBD Some older material points the same endpoint at different hosts. In particular, GetAuthToken has been published against more than one host family. If you are migrating from an older document, confirm your host list with Cheggout before switching environments. Tracked in Open Items.

Transport requirements

• HTTPS only. Plain HTTP is rejected in both environments.
• Server-to-server calls originate from whitelisted IPs. Share your egress IPs during onboarding and again whenever your infrastructure changes.
• JSON request and response bodies, UTF-8.

Caching and pre-fetching

Experiences should open instantly. Two things are safe to prepare in advance.

Cache the catalogue

The deals catalogue is not user-specific and is explicitly cacheable. Refresh it on a schedule into your own store and serve your storefront from that cache rather than calling Cheggout on every page view.

Inventory is separate and short-lived: getCatalogueInventory returns a ttlSeconds value (currently 180 seconds) and should be re-checked before you show a buy action, so you can mark an item "limited stock" or disable it.

Nightly / hourly ──► getCatalogue ──► your cache ──► your storefront
Before buy CTA   ──► getCatalogueInventory (≤180s old) ──► enable or disable

Pre-fetch tokens

Tokens are long-lived enough to fetch ahead of the moment you need them.

• The reference token used for reward creation is designed to be refreshed by a scheduled job on your backend — hourly — and cached, not minted per request.
• User tokens are minted per user and should be obtained when the session starts rather than at the moment the user taps.

Both let the user-facing call be a single round trip. See Tokens for lifetimes and refresh guidance.

What not to cache

Never serve a reward, a coupon code or the result of a reveal from a shared or HTTP cache, and never reuse one across users. They are per-user, single-use, and subject to eligibility that can change between calls.

That is not the same as discarding them. You must persist a revealed reward and a delivered coupon code to your own per-user store the moment you receive it — a reveal is one-shot, and if you lose the payload the user loses the reward. See Scratch card lifecycle.

Configuration checklist

Make all of this environment-configurable before you start:

• API base URLs per product line
• CHANNELID (may differ between UAT and production)
• Signing key pair and Cheggout's public key, per environment
• API key and secret, if you use the Deals Store
• Widget script URL, if you use the web surface
• Hosted launch URLs, if you use a microsite

Next

• Onboarding — how to get credentials for both environments.
• Testing — verifying in UAT.