Widgets
FYNXT Incentive widgets are drop-in UI components — rebate summaries, IB network tables, contest leaderboards, loyalty balances — that you embed directly into your client portal or website. Each widget ships as a single Web Component, so the same tag works in React, Angular, Vue, Svelte or plain HTML, with no build step required.
<fynxt-rebate-summary> on the page, and pass identity in via an attribute.
Styling is isolated in a Shadow DOM, so widgets never clash with your host CSS.
What widgets are
A widget is a self-contained view onto a participant's incentive data. It renders its own layout, fetches its own data from the FYNXT Incentive backend, keeps itself up to date, and exposes a small, declarative API through HTML attributes. You do not import React, manage a data store, or wire up API calls — the widget runtime does all of that for you.
Widgets are designed for three audiences:
- Brokers embedding participant-facing dashboards into an existing client portal.
- Partners / IBs showing rebate and sub-network performance on their own sites.
- Marketing & CMS pages that need a leaderboard or loyalty badge with no backend at all.
Widget catalog
Each widget is a custom element with the fynxt- prefix. Swap the tag, keep the
rest of the integration identical. The widget reference
documents every attribute.
| Element | What it shows |
|---|---|
<fynxt-rebate-summary> | KPI cards: total, pending and on-hold rebates earned for the participant. |
<fynxt-rebate-trend> | Monthly rebate-earnings chart, broken down by commission type. |
<fynxt-ib-network> | Sub-IB network table — downline volume, active clients and earnings. |
<fynxt-referral-summary> | Referral performance: clicks, registrations, conversions and attributed value. |
<fynxt-leaderboard> | Live contest leaderboard with rank, participant and score. |
<fynxt-loyalty-balance> | Loyalty points balance and current tier for the signed-in participant. |
How they work
The lifecycle of a widget on the page is:
- Load the runtime. A single script registers every
fynxt-*custom element and boots a shared runtime. You only load it once, no matter how many widgets are on the page. - Resolve identity. The widget reads an
embed-token(a short-lived JWT issued by your backend) or, for backend-less pages, identity attributes. Nothing renders until identity is verified. - Fetch & render. The widget requests exactly the data it needs from the FYNXT Incentive API, renders inside its Shadow DOM, and subscribes to live updates.
- Stay in sync. Real-time events (a new rebate settles, a leaderboard reshuffles) are pushed to the widget and it re-renders in place.
Shared runtime & data
When several widgets sit on the same page they often read the same underlying data — three rebate widgets all need the participant's rebate summary, for example. The runtime is built so that this costs you one network round trip, not three:
- One shared client. All
fynxt-*elements register against a single runtime instance, with one shared cache — not one fetch layer per widget. - Request de-duplication. If two widgets request the same endpoint in the same tick, the runtime issues a single request and fans the result out to both.
- Batched reads. Widget data needs are coalesced into a single backend-for-frontend (BFF) call within a microtask window, so a dashboard of six widgets bootstraps in one request.
- One token, one socket. Every widget shares the same
embed-tokenand a single real-time connection — updates fan out to all subscribed widgets.
Next steps
Embedding & auth
Load the runtime, choose Access Key Embed or Attribute Auth, and add your first widget.
Embedding guide →