Widgets in context

Mock homepages for the four front ends that consume our support modules. All four now include Site Search in the masthead: TF, seller, and partner run the embed loader, while TFH renders the same public API results in its own search chrome. Support chat, the inline knowledge base, and web phone run alongside it. The real loader and API paths execute inside these mocks, so the interaction proves the host contract rather than a static mockup. Sales chat has its own offer-page demos on /chat.

If you own one of these portals: each widget is one <script> tag. The loader builds its own iframe, so none of your CSS reaches us and none of ours reaches you, which also means you cannot restyle the panels from your side. Configure heading, intro and colours in Admin → Widgets instead, and they will match your palette rather than ours. Your real work is placement and context: keep launchers clear of sticky headers, cart drawers and consent banners, and pass the signed-in visitor's email at init so returning members are greeted by name. In practice, trulyfree.com runs the full widget set along a shopper's path, seller.trulyfree.com pairs its own KB and Site Search with HQ chat for onboarding questions, and partners.trulyfree.com pairs its own KB and Site Search with HQ chat for commission and payout queries.