SdksWidgets
Widget SDKs
Planned client-side SDKs for embedding Wistfare into websites, Flutter apps, React apps, and mobile experiences.
Widget SDKs are the client-side counterpart to the server SDKs. They are intended for teams that want to embed Wistfare directly into a website or application UI instead of building their own front end on top of the HTTP APIs.
Current status
The widget surfaces described in this section are planned or preview-level. If you need a production integration today, use the Server SDKs and keep the UI under your own control.
What Widget SDKs Will Eventually Cover
- Embedded chat and voice experiences.
- Pre-chat forms and visitor context collection.
- Theme and branding hooks for host applications.
- Event callbacks for analytics and workflow automation.
- WebSocket and real-time session handling behind a simpler client API.
Availability Snapshot
| Surface | Intended distribution | Status | Best option today |
|---|---|---|---|
| Web widget | Hosted script or managed JavaScript embed | Planned | Use the server SDKs plus your own web UI. |
| Flutter widget | Published Flutter package | Planned | Use Dart server SDKs for backend work and your own Flutter UI. |
| React widget | Published React package | Planned | Use server SDKs plus your own React components. |
| React Native widget | Published React Native package | Planned | Use server SDKs or direct HTTP from your backend. |
| HTTP fallback | REST-based backend integration | Available path | Useful for custom front ends and private previews. |
Choosing the Right Integration Path
Use server SDKs when
- You need a production integration right now.
- Your backend owns payment, wallet, or staff workflows.
- You want the most mature examples and the widest language support.
Use widget SDKs when
- You want a drop-in customer-facing chat or voice surface.
- You prefer a hosted client integration model.
- You can work with preview or planned functionality until the widget packages are published.
Use HTTP fallback when
- You are building a custom UI that does not map cleanly to the default widget experience.
- You need one missing endpoint before the SDK catches up.
- You want to prototype the client experience before locking into a widget package.
