How Cheggout works
Every Cheggout integration is a variation on one shape: your systems authenticate the user and report that something happened; Cheggout decides what the user has earned and returns it; your app renders it and reports back what the user did.
Platform architecture
The boundary matters: the signing key and any API secret live on your backend, never in your app or website. Client surfaces carry short-lived tokens that your backend obtained.
The universal request flow
Three things are always true:
- Authentication happens server-side. Your backend proves who it is with a signature or an API key. The client only ever holds the result.
- Cheggout decides, the client renders. A "no reward this time" answer is a normal, expected response — not an error.
- Tracking is your responsibility to fire. Cheggout returns tracking URLs with each item; the integration is only complete when impressions and clicks are being fired. Reporting and settlement depend on it.
Where each module sits
| Module | Publisher reports | Cheggout returns | Client renders |
|---|---|---|---|
| Scratch Cards | A qualifying event (payment, article read) | Card IDs, then the revealed reward | Card, scratch animation, reward |
| Advertisement | A placement is on screen | Banner or store creative + tracking URLs | The creative |
| Marketplace | An authenticated session | The whole experience | SDK screens or a microsite |
| Coupons & Deals | A coin burn / claim | Catalogue, then a coupon code | Your storefront |
Two-phase reward assignment
The scratch-card module deliberately splits issuance into two phases, and this is worth understanding before you read the API reference.
Phase 1 tells you a card exists. The reward behind it is chosen only when the user actually scratches, which stops inventory being burned on cards nobody opens. Targeting parameters you send in phase 1 are stored and applied at reveal.
Next
- Core concepts — the identifiers and vocabulary used everywhere.
- Integration models — which modules and surfaces to combine.