Show your own data in the messenger

Plenty of questions are answered by data you already have: where an order is, how much of an allowance is used, when a subscription renews. Custom widgets let the messenger fetch that from your backend and show it, so the customer sees the answer instead of asking for it.

Set up the connection

Under custom widgets, enable the feature and give the API URL Gleap should call. You can add custom headers if your endpoint needs authentication.

Your endpoint receives the request and returns JSON describing what to display.

What to return

Two shapes. Return widgets with a list, for several blocks on the home screen, or view with a single one, for a detail screen.

Each widget can be built from typed content, which is themed to match your messenger and validated on the way in:

{
  "widgets": [
    {
      "id": "order-status",
      "title": "Live order",
      "content": [
        { "type": "text", "text": "Your package arrives Tuesday." },
        {
          "type": "button",
          "label": "View order",
          "style": "primary",
          "action": {
            "type": "open-view",
            "viewName": "order-detail",
            "payload": { "orderId": "A-1042" }
          }
        }
      ]
    }
  ]
}

A button with an open-view action opens another view, passing a payload your endpoint receives — which is how a summary leads into a detail screen without leaving the messenger.

Or raw HTML

Instead of typed content you can return an html string. It's sanitised before it's mounted, and click handling still works through data attributes, so buttons in your markup can open views and trigger actions.

If you set both, the HTML wins and the typed content is ignored — worth knowing when a widget renders differently from what you expected.

Prefer typed content where it fits. It inherits your messenger's styling automatically, so it keeps looking right when you change your colours, and it can't break the layout. Reach for HTML when you need something the typed blocks don't cover.

Your endpoint decides what a customer sees, so it has to establish who is asking. Don't trust an identifier that arrives in the request — verify it against your own session or a signed value, exactly as you would for any other API that returns account data.

Keep it fast

The widget is fetched while someone is waiting with the messenger open. A slow endpoint is visible in a way a slow background job never is, so return something quickly — a status and a button beats a complete picture that takes three seconds.