Where sidebar apps show your data to agents, custom widgets show it to customers. Gleap asks your backend what to render on the messenger home and displays the response.
Typical use: the customer's current order and its status, their open invoice, the state of something they're waiting on — answered before they ask.
In your project settings, under Custom widgets, turn on Enable custom widgets, provide an API URL, and add any headers your endpoint requires to authenticate the caller.
One endpoint serves everything. Gleap posts to it with a kind telling you what it wants: widgets for the home screen, or view with a view name when the customer opened one of your views.
The request carries the acting contact — name, email, and custom data — so you can look them up in your own system. That identity is verified by Gleap before your endpoint is called; the messenger can't ask about somebody else's account.
Content items of these types: text, image, button, key-value, divider and html. Anything else is dropped rather than rendered.
Buttons carry one of four actions:
open-url — send them to a page.
open-view — open one of your own views inside the messenger, with an optional payload. This is what makes widgets more than a dashboard: a list of orders where each opens its detail.
http-request — call back to you.
custom-action — trigger a custom action your app registered with the SDK.
Your endpoint must be reachable on a public host over HTTP or HTTPS. Private and loopback addresses are refused.
Responses time out after a few seconds, and oversized ones are rejected.
There's a ceiling on how many content items are rendered, and long HTML is truncated.
None of these bite a normal widget. They bite the version that tries to render a customer's entire order history on the home screen.
The home screen is glanced at, not read. One widget answering the single most common question beats four competing for attention.
Return nothing when you have nothing — an empty widget takes up space and teaches people to ignore that area.
And keep it quick: this runs while the customer waits for the messenger to open, so a slow endpoint makes your support look slow before anyone has typed a word.
