Versioning
TBD Cheggout does not publish a formal versioning or deprecation policy. This page describes what is observable today and what you should do about it. Establishing a policy is an open item.
What is observable today
API paths are unversioned. Endpoints live at /api/<name> with no version segment, so a change
to an endpoint's behaviour changes it for every caller at once.
Documents carry versions, contracts do not. The published integration documents are versioned — the SDK guide, the server API guide, the deals guide each have their own revision history — but those versions describe the document, not a negotiable API version. You cannot request an older contract.
Product lines evolve independently. The Deals Store moved from RSA signing to API keys in a document revision while the Rewards Center kept signed envelopes. Expect each product line to move on its own schedule.
SDKs and the widget are distributed artifacts. You receive a specific AAR, framework or script build and stay on it until you take a new one. That gives you control over when a client-side change lands — provided you know a new build exists.
What this means for you
Without a version negotiation mechanism, your protection is defensive implementation.
Tolerate new fields. Parse responses permissively — an unknown field must not break your deserialisation. This is the single most valuable habit, since additive changes are the most common kind.
Do not depend on field order or on the exact shape of undocumented fields.
Handle unknown enum values. New reason codes, new couponType values or new error strings
should degrade gracefully rather than throw.
Pin your SDK and widget builds in source control, and treat an upgrade as a change with its own testing cycle.
Keep hosts and credentials in configuration, never hardcoded, so an environment or host change is a config deploy rather than a release.
Re-run your UAT suite whenever Cheggout tells you something changed — and ask, periodically, whether anything has.
Establishing a change path
Because there is no published notification channel, agree one with your Cheggout contact during onboarding. At minimum, ask for:
- A named contact who will notify you of API or SDK changes.
- Advance notice for anything that changes an existing contract.
- The current SDK and widget build identifiers, so you can tell whether you are behind.
- A UAT window to verify a change before it reaches production.
Put the agreed notification path in writing. It is the practical substitute for a deprecation policy.
Release notes
TBD No release notes are published for the APIs, the SDKs or the web widget. There is no changelog to subscribe to and no build-version endpoint to poll.
Track your own: record the SDK version, widget build and document revision your integration was certified against, so that when behaviour changes you can tell what moved.
What a policy should cover
For reference, the items Cheggout would need to publish for this page to become actionable:
| Item | Why it matters |
|---|---|
| Version identification | Knowing which contract you are on |
| Backward-compatibility guarantees | Which changes can happen without notice |
| Deprecation window | How long you have to migrate |
| Notification channel | How you find out |
| Release notes | What actually changed |
| SDK support window | How long an old build keeps working |
| Migration guides | How to move between contract versions |
These are tracked on Open items.