Skip to main content
Start by deciding how much UI ownership you want. The lower-level path gives you maximum control. The component paths give you faster setup and a supported default experience. Decision workflow showing when to use the Core SDK, React ExperienceWidget, or web component.

Core SDK

Choose the core SDK when your team wants to design every screen and connect the SDK state to your own components, router, analytics, and checkout behavior.
ProsTradeoffs
Full UI controlYou own every state and edge case
Works with any frameworkMore application code
Best fit for custom flowsRequires deeper understanding of JourneyView
Use this path if your customer journey is highly branded, your product page already has a complex state model, or you need to integrate with a framework that does not have a Fanfare adapter.

React components

Choose React components when you want a supported UI layer but still need branding, slot overrides, callbacks, and custom copy.
ProsTradeoffs
Fastest React setupThe widget owns the default layout
Supported journey UIDeep customization uses slots or render props
Built-in theming and i18nYou still need to handle checkout and app routing
Use this path for most React storefronts and launch pages. You can start with ExperienceWidget, then move specific sections into slots as your design becomes more bespoke.

Web components

Choose web components when you need to embed Fanfare into a static page, CMS, tag-managed page, or non-React application.
ProsTradeoffs
Framework-agnostic embedCustomization is mostly attributes, theme config, and host CSS
Good for CMS and static pagesComplex UI customization usually moves to core or React
Events bubble through the DOMType checking depends on your host tooling
Use this path when the host application cannot mount React directly, or when the integration team needs a simple HTML custom element.

Hybrid path

Many teams use more than one path:
  • Use ExperienceWidget for the first launch.
  • Add slots for brand-critical states.
  • Move to useExperienceJourney or core SDK for a fully custom UI.
The important rule is to keep your application logic based on the public journey view (JourneyView/SequenceView) and the actions it exposes. Do not build behavior around private implementation details or assumptions about why a consumer reached a state.