Activity & events — Mimeo docs
Activity & events
The Events section is where the event stream becomes visible: a feed of everything that has happened on your instance, and a registry of every event name it has ever seen.
Events drive everything in Mimeo — they build people's timelines, trigger flows, release gates, and feed segment conditions. This section is the observability for that stream, in two tabs: Activity, the feed of individual occurrences, and Events, the registry of names.
Activity: the feed
Events → Activity is every event on the instance, newest first — the ones your systems POST to the API, the ones the engine emits itself (tag_added, flow_entered and friends), and the ones an import recorded. Filter by event name or by source, and page back as far as you need.
| Source | What it means |
|---|---|
api |
Sent from outside — your app, your checkout, an agent. |
system |
Emitted by Mimeo itself when state changes —tag_added, field_changed,flow_entered and the rest. |
import |
Recorded during a CSV import. |
Click any row and a panel opens beside the list with everything that event carried: the payload as readable key/values and as raw JSON, a link to the person, the source, and the timestamp.
The feed refreshes on demand, not live. A busy instance would otherwise scroll under your cursor while you read it. Hit refresh when you want the latest.
Events: the registry
Events → Events is one row per event name — every name this instance has ever seen, with its occurrence count, sources, and first/last seen. Nothing is declared ahead of time: a name registers itself the first time it arrives, which makes this the one registry that can't drift from reality. It's also the live trigger vocabulary — every name here is something a flow can trigger on, a gate can wait for, and a segment can ask about.
Click a name and the detail panel opens beside the list:
- A 30-day volume sparkline — the recent rhythm of the event.
- The data shape — what this event's payloads actually carry.
- Used in — every flow and segment listening for the name.
- The last 10 occurrences, each linking to its person.
The data shape
The shape is the merged picture of every payload ever sent under the name. For each payload key it shows the JSON types seen, the share of occurrences that carried the key, and one real example value. It answers "what does this event send?" without reading a single raw payload — which is exactly what you want to know before writing a trigger match or an event_occurred condition against it.
The shape is a glimpse, not an archive: at most 200 distinct keys are described (occurrences beyond the cap still count), and example values are truncated past ~500 bytes.
Used in
The registry says what an event sends; used in says what listens. It lists every flow that triggers on the name, waits for it at a gate, or fires it from a fire_event step — and every segment with an event_occurred condition on it. Before renaming an event in your app's code, this is the panel that tells you what would silently stop firing.
The person timeline reads the same way
A person page's Timeline tab uses the same list-plus-panel reader: click any row to see its full payload and details. It's the activity feed narrowed to one person, so one person's history and everybody's read the same.
For agents
The same eyes exist on every surface. GET /api/v1/events is the feed and GET /api/v1/event_types is the registry, shapes and used-in included. Over MCP, list_events and list_event_types do the same — and describe_schema includes event_names, so an agent writing a flow starts from the vocabulary that actually exists.