Headless API

No SDK, no widget, no microsite. Your systems call Cheggout's APIs and you render everything yourself. This is how publishers such as large fintechs and media platforms integrate when the experience has to be entirely theirs.

Available

The trade

You get complete control of the experience, no third-party code in your app, no SDK upgrade cycle, and the same platform capabilities as every other surface.

You give up the ready-made components. Every scratch card animation, every offer tile, every reward screen is yours to design, build and maintain.

Cheggout's backend remains the source of truth regardless: targeting, eligibility, coupon issuance, inventory, fraud controls, frequency caps and reporting stay server-side. Going headless changes who draws the pixels, not who decides what appears.

The shape

Everything Cheggout returns is JSON. Nothing renders itself.

Two product lines, two auth schemes

	Rewards Center	Deals Store
Gives you	Scratch cards and rewards	Coupon catalogue and delivery
Auth	Signed envelope + bearer tokens	API key header
Host	`rewardscenter.cheggout.com`	`hotdeals.cheggout.com`
Complexity	Medium — RSA signing, two token types	Low — a static header

If you integrate both, you implement both schemes. They are independent.

Rewards Center — the flow

Note where the user token is minted: at session start, not at the moment the customer scratches. Minting it inside the scratch handler puts a signed round trip on the critical path of a gesture the user is already watching.

Five endpoints, two token types, one important rule: reveal is one-shot, so persist what you receive. Full walkthrough: Headless scratch cards.

Deals Store — the flow

Four endpoints plus a webhook you host. The coin economy stays yours; the prescribed ordering is burn, deliver, then refund or retry. Full walkthrough: Coupons & Deals.

What you must build

Beyond the API calls, headless integration means owning some things the SDK would otherwise handle.

Tracking. You fire impression and click URLs yourself. Parse the <track> and <clicktrack> tags out of the tagged strings and issue a plain GET. This is not optional — attribution and reporting depend on it. See Tracking.

Token lifecycle. Scheduled refresh for the reference token, per-user minting for user tokens, single-flight refresh, retry-once on 401.

Response rendering. HTML fields such as terms, redeemSteps and details arrive as list markup — sanitise before rendering.

State persistence. Revealed rewards and delivered coupons must be stored by you. The platform will not re-issue them.

Error handling across four response shapes. See Error codes.

What you don't have to build

Targeting, eligibility, frequency caps, fraud controls, coupon pools, inventory, campaign scheduling, merchant relationships and settlement. All of that stays server-side.

Deciding between headless and components

Question	If yes
Must the experience be entirely your design?	Headless
Do you have engineering capacity for the UI?	Headless
Are you on a platform with no Cheggout SDK — Flutter, React Native, a backend service?	Headless
Do you want to ship in days rather than weeks?	Components or hosted
Is this a secondary feature rather than a core surface?	Hosted

A hybrid is common and sensible: headless for a post-transaction reward on a screen you already own, hosted or SDK for the full marketplace.

Before you start

Credentials for the product lines you need
Egress IPs whitelisted
Signing implemented and verified locally, if using the Rewards Center
A virtualId scheme decided
A ledger keyed on extTransactionId
A plan for firing tracking URLs
Storage for revealed rewards and delivered coupons

The trade​

The shape​

Two product lines, two auth schemes​

Rewards Center — the flow​

Deals Store — the flow​

What you must build​

What you don't have to build​

Deciding between headless and components​

Before you start​

Next​