Documentation Index
Fetch the complete documentation index at: https://docs.myme.so/llms.txt
Use this file to discover all available pages before exploring further.
system.activity is the platform’s operator-facing surface for “things that happened” — sync progress, errors, reauthorisation prompts, scheduled-job results. Each activity is an item, attributed to the Connection that produced it, queryable through the standard item filter DSL.
The pattern lets connectors and platform components surface state without bespoke notification or log infrastructure. Listings, filters, audit, and permissions all work the same way they do for any other item.
Severity levels
| Severity | Meaning | Example |
|---|---|---|
info | Routine state. Schedule completed, n items synced, nothing actionable. | ”Polled feed, fetched 3 new entries.” |
warning | Degraded state, no user action required. | ”Upstream rate-limited; backed off, will retry.” |
error | Something failed; the system has handled it (retry, skip) but the operator may want to know. | ”Webhook delivery failed; entered DLQ.” |
action_required | The connector cannot proceed without operator intervention. | ”OAuth re-authorisation needed for Calendar Connection.” |
action_required slice surfaces in the console as a Repairs-style inbox; the others stream through a feed.
Fields
| Field | Meaning |
|---|---|
connection_id | The Connection this activity is attributed to. |
severity | One of the four levels above. |
summary | Short human-readable description shown in lists. |
detail | Optional structured payload for deep-dive surfaces. |
system.* type, activities use the bounded lifecycle active | revoked (not the universal three-state). Activities are also tier-less — system.* items don’t carry a tier field. Operators flip activities to revoked once they’ve handled them; the row stays in the audit trail.
Optional connection-level feed behavior
A Connection can carryfeed_activity: true in its properties, which causes the operator console to render that Connection’s activity rows in a feed-style surface (high-volume, less prominent) rather than the default library-style listing. The flag rides on the system.connection item, not the activity item itself — system.activity doesn’t have a tier field. The underlying rows observe the bounded active | revoked lifecycle.
Why items, not a separate log table
Treating activity as items means the platform gets querying, retention, search, audit, and permissions for free through the same surfaces. No separate log infrastructure, no separate UI to build for the console — list views work uniformly. The pattern matchessystem.device, system.credential, system.webhook, and system.app: items with reduced operability in a reserved namespace. See System types for the wider pattern.
How operators read activity
Standard item queries:properties.* — the filter DSL addresses item properties as properties.<field>. The full filter grammar is in Search and query.
A console view filters by severity and groups by Connection; an SDK consumer queries directly. The data is the same in both cases.