Widget vs app
message.com ships two distinct front-end surfaces. The widget is the chat bubble your customers see on your website. The app is the dashboard at app.message.com where your agents answer those chats. They share one backend, one workspace, and one set of conversations.
The widget
The widget is a vanilla JavaScript bundle (~50KB gzipped) that you embed on your site with a single <script> tag. It boots in a Shadow DOM for full style isolation, opens a chat panel, manages a visitor cookie, and connects to the widget Socket.io namespace for real-time messages.
The widget is anonymous on first load. The bundle reads its config from GET /widget-config?embedId=<id>, which requires no authentication. Identity is added later through Message.identify. The widget can be theme-customized through dashboard settings or through data attributes on the <script> tag.
The app
The app is the agent dashboard. It lives at app.message.com and uses the same REST API your integrations can call. Agents log in with email and password, get a JWT, and use it as a bearer token across both REST calls and the agent Socket.io namespace.
The app is built with Next.js. It is static-exported and served from a single droplet behind Cloudflare. The unified inbox queue, ticket view, chat feed, and call view are all components in the app codebase.
Shared backend
Although the widget and the app are visually different, they share one Fastify server, one Postgres database, and one Socket.io instance. A visitor message sent through the widget arrives in the app's queue within milliseconds. An agent reply sent through the app appears in the widget without a page refresh.
Which one should you build against
It depends on what you are doing:
- Embedding chat on your marketing site: install the widget through the widget installation guide.
- Wiring chat into a logged-in product: install the widget and call Message.identify on session start.
- Building an integration that creates tickets from a webhook: skip the widget. Use the Tickets API server-side.
- Building a third-party agent app (rare): the REST API + agent Socket.io namespace can drive a custom agent UI, but this is not a common path.
A note on naming
Older Intercom-style docs use "messenger" for the customer-facing widget and "inbox" for the agent app. message.com sticks with "widget" and "app" because they are unambiguous and match how engineers describe each surface.