How Messageboard works

Messageboard does one thing well: you send a message via a REST API, add a widget for that message name to a dashboard, and keep later versions flowing into that same surface.

That sentence is simple. The architecture behind it is what makes it useful.

The core model

Every interaction revolves around three concepts:

1. Messages: text payloads identified by a name you choose or one we generate.
2. Dashboards: collections of widgets, one per unique message name.
3. Widgets: the rendered view of the latest message version.

When you POST /api/messages with a payload, Messageboard creates a new message. When you POST again with the same name, it creates a new version of that message. The widget always shows the latest version, but users can cycle through history.

{
  "id": "deployment-status",
  "content": "Deploy v1.4.2 started — 14:23 UTC",
  "contentType": "TEXT"
}

Why versioning matters

Most message systems are append-only. That works for logs. It is less useful for a current-state dashboard where people want the latest answer first.

Messageboard gives you both layers:

• every POST is a write event,
• every widget is a current-state surface,
• every message name has a navigable history.

Service architecture

Client -> REST API -> message store
                   -> auth and account layer
                   -> dashboard UI

The backend stores versioned message rows and account boundaries. The frontend renders a dashboard where each widget reflects the latest known state for a message name after you add that widget to the dashboard.

Multi-tenancy

Every resource belongs to an account: messages, dashboards, API keys, and users. Accounts stay isolated by default. Teams can invite collaborators into the same account so they share dashboards and the message namespace that powers them.

The layout model

A dashboard holds one widget per unique message name. Widgets can be auto-placed or manually arranged in edit mode. That keeps first use fast while still allowing customization later.

What this means for developers

The API is the surface area you integrate with. The dashboard is the display layer you get out of the box.

If you want to send deployment states, alert summaries, release notes, or job output, start at the quickstart and the API domain.