Skip to main content
Everything here goes through the controller, your handle on the mounted widget. Pick your framework with the switcher next to the table of contents.

Before you start

A mounted widget

The controller only exists once the widget is installed and mounted in your app.

Get the controller

<RinggWidget config /> builds the controller for you. onReady hands it back:
It fires once, after the widget’s first render, and the widget destroys the controller when it unmounts. Everything on this page works off that value. If you built the controller yourself (own the lifecycle), you already have it.

Lifecycle events

The React Native and Flutter widgets emit five lifecycle events on an in-memory event bus. The web widget uses the same names as browser CustomEvents, with two differences: it never emits ringg:component_acknowledgement, and its ringg:calendar_booking has no "failed" status. See web widget events.
ringg:calendar_booking and ringg:component_acknowledgement only fire when the agent sends interactive components. An agent configured for plain voice or text never emits them.
controller.eventBus.on returns an unsubscribe function.
Subscribe in an effect and return the unsubscribe function; handlers registered during render accumulate on every re-render and fire several times per event.

Controller methods

Call these to drive the widget from your own buttons, deep links or navigation events.
The controller also exposes methods for component responses, Block Kit actions and dynamic-data extensions. The bundled widget calls those on itself while rendering interactive components, so a normal integration does not need them.

Reading state

Each store has a hook that re-renders your component when its snapshot changes. Use these to build your own UI, or to mirror the widget’s state elsewhere in your app.
Each message carries name, message, isSelf, timestamp, an optional sourceUrl for retrieved sources, and componentType with componentData when the message renders a component instead of text.

Interactive components

Agents can send interactive components into the chat thread instead of plain text. All six types render natively, with no work on your side beyond mounting the widget.Configure which components an agent can send from the dashboard. See Chat Components for authoring them.

Agent-triggered app actions

An agent can fire actions during a conversation, for example to open a screen or focus a field. On the web these become browser events. React Native has no ambient event bus, so you supply the handler through ports and receive the same payload.
Set eventLogs: { enabled: true } in config to also show each fired action as an inline pill in the chat thread, which makes these easy to watch while building.

Ports reference

ports overrides what the widget wires on its own. Every entry is optional: supply one and yours is used, leave it out and the default applies.
ports is read once, when the widget builds the controller. Changing it later has no effect; changing config rebuilds the conversation from scratch.

Own the lifecycle yourself

When the widget cannot own the transport, build the controller and pass that instead. defaultUrlResolver keeps the Ringg endpoints without you naming them:

Verify your handlers

  • Open and close the panel once, then confirm one ringg:widget_status event per action.
  • Start and end one conversation, then confirm ringg:conversation_status carries a callId.
  • Navigate away and back, then confirm listeners are not duplicated.
  • Submit and skip feedback in separate runs if the feedback screen is enabled.
  • Unmount the screen during a call and confirm the microphone indicator clears.
To let the agent show forms, cards and slot pickers in the thread, build them in the dashboard: Components.

Next steps

Review conversations in Logs

Each conversation’s transcript and analysis, under call type Webcall.

Read Analytics

Totals and trends across every conversation.