Even notifications
Minyu provides outbound event delivery to external systems through signed webhooks. Unlike traditional change feeds, notifications in Minyu are triggered by semantic events derived from the data model itself—either when business meaning changes or when relevant structural mutations occur across related data.
Notifications are evaluated after data changes are committed and delivered with a short system delay. They are designed for external synchronization, automation, and reactive integration workflows where understanding what changed and why matters more than observing low-level mutations.
Two event types, one semantic model
Minyu supports two complementary event types: classification events and mutation events. Both are defined declaratively against the schema and remain stable as the data model evolves.
Classification events: detecting state transitions
Classification events emit notifications when a boolean classification changes state on a row. They are used to detect meaningful transitions—entering or leaving a business-defined condition—rather than continuous truth.
Only explicit transitions trigger events.
Example
A classification event configured as person.is_over_18: false → true emits a notification exactly once—when a person becomes an adult. It does not emit repeatedly while the condition remains true.
Because classifications are continuously evaluated as data or time changes, classification events can capture both structural updates and temporal transitions without additional logic.

Mutation events: relationally aware change detection
Mutation events trigger notifications based on data mutations, but with full awareness of relations and paths in the model.
They can detect:
- row creation, update, and deletion
- relation creation and removal
- field-level updates
- changes deep inside related data
Mutation events are defined by selecting what to observe, not by subscribing to an entire table.
Example
A mutation event can trigger when: - a phone number is linked to a person - a specific field on a related row changes - a relation edge is removed without emitting events for unrelated updates.
This makes mutation events suitable when full synchronization or fine-grained change tracking is required—without exposing raw database change streams.

Declarative configuration tied to the data model
Both classification and mutation events are configured directly against the schema through the Notifications interface. Events are inactive until saved and become effective immediately—no redeployment or system restart is required.
Events themselves do not deliver anything. Delivery is defined separately through webhooks, which bind:
- one event
- one authentication configuration
- one HTTPS endpoint
This separation ensures that event meaning, security, and delivery behavior remain clearly isolated.
Secure and traceable webhook delivery
Notifications are delivered via authenticated webhooks. Minyu supports HMAC-SHA256 signing to ensure authenticity and payload integrity, and automatically retries failed deliveries using at-least-once semantics.
Payloads are intentionally minimal and include only webhook identifiers and affected row IDs. Full row data is not embedded; external systems are expected to fetch any required details via the API.
Every webhook delivery attempt—including retries—is recorded in the Webhooks Log, providing full visibility into delivery status, failures, and retry behavior for auditing and operational tracking.
Why this matters
Most integration layers force consumers to infer meaning from technical noise. Minyu does the opposite: it elevates meaning to a first-class concept.
By defining events in terms of classifications, relations, and explicit transitions, Minyu enables integrations that are:
- stable across schema evolution
- aligned with business intent
- simpler to reason about
- cheaper to maintain
External systems are notified when something significant happened, not when something happened somewhere.
→ Read more: Notifications