Skip to main content
A widget is a piece of UI that you build on top of the SDK to expose a Cashback Hive capability on your site. The SDK is headless — it deliberately ships no UI — so widgets render in your own markup and styling and fit your design. Widgets are enabled per property in the publisher portal. The capabilities a widget depends on (for example listing offers, or member sign-in) are only available when the corresponding widget is enabled for your property.

​
Available widgets

Offers

Browse and search the cashback offers available to your property, and send shoppers to retailers via tracked links.Uses: offers.list(), offers.get(), openOffer(), trackingUrl()

Activate

Let a visitor sign in as a Cashback Hive member so their purchases earn cashback, and show their balances and activity.Uses: auth.*, member.*, the auth:change event

​
Reference implementations

Each widget page includes a complete, copy-pasteable implementation in two flavours:
  • Vanilla JavaScript — framework-free, for static sites, CMS templates and tag managers.
  • React / Next.js — a Client Component built on the useCashbackHive() hook.
They’re intentionally unstyled beyond basic structure so they drop into your existing design system. Class names in the React examples are placeholders you should replace.

​
Common structure

Every widget follows the same three steps:
  1. Wait for the SDK. Use the cbh:ready event or initialized check described in Lifecycle. Never call the SDK before this.
  2. Call the SDK and render. Fetch data (offers.list(), member.get()) and render it. Handle the loading, empty and error states — in particular a 403 from the API means the current origin isn’t allowed.
  3. Subscribe to changes. Use sdk.on("auth:change", …) so the widget reflects sign-in/sign-out that happens elsewhere on the page (another widget, another tab, or the SDK’s background token check on load).