MotifEngine turns what your users already do into XP, achievements, missions, points and rewards. Your backend sends events, your team publishes the rules, and every reward lands in a ledger that never counts twice.
{
"event_type": "order.completed",
"user_id": "you",
"payload": {
"order_id": "order-1001",
"total": 129.9,
"currency": "USD",
"payment_status": "paid"
}
}Simulated in your browser · same semantics as the API
Engagement logic usually hides in cron jobs, spreadsheets and one-off scripts. MotifEngine gives it one home: trusted events in, published rules in the middle, ledgered rewards out.
Follow a single order from your backend to a reward the customer can hold. Each move is a real part of the engine, shown with the shape it has in the API.
A trusted event arrives with a stable event id. It is validated against an immutable contract version, deduplicated, written with an outbox row, and answered with a 202 receipt before any effect runs.
{
"event_id": "order-1001-completed",
"event_type": "order.completed",
"user_id": "user-42",
"payload": {
"total": 129.90,
"payment_status": "paid"
}
}Rules are data, not customer code: when an event type arrives, if a restricted condition holds, then typed actions run. Drafts never execute. Publishing freezes a version, and optional UTC windows bound a campaign.
{
"event_type": "order.completed",
"conditions": {"eq": ["$.payment_status", "paid"]},
"actions": [
{"type": "award_xp", "amount": 25},
{"type": "award_points",
"currency": "loyalty", "amount": 50}
]
}XP accumulates per external user and resolves to the level whose threshold it has reached. Missions count matching events toward a target; achievements unlock after a required count. None of it is spendable.
{
"total_xp": 275,
"level": 3,
"level_name": "Regular",
"next_level_xp": 500
}Each currency keeps its own append-only history. Awards, spends, expiring lots and conversions are entries with idempotency keys, so a retry can never pay twice and a correction never deletes the original row.
{
"currency": "loyalty",
"amount": 50,
"type": "award",
"idempotency_key":
"order-1001-completed:completed_order_reward@v3:1"
}A reward is free or costs one active currency. Each redemption reserves points, records every provider attempt, and stays in delivering when the outcome is unknown, until a status check or retry settles it.
reserved → delivering delivering → fulfilled timeout → outcome unknown points stay reserved status check → fulfilled
Four proofs you can play. Each one runs the engine’s semantics in your browser, and each one pays out an achievement when you clear it.
Give 50 loyalty points to paid orders of 120 or more. Nothing else.
{
"event_type": "order.completed",
"conditions": {"gt": ["$.total", 100]},
"actions": [{"type": "award_points", "currency": "loyalty", "amount": 50}]
}Ten parts, one contract. Each row names the endpoint where it lives, so your engineers can check every word.
Receive each fact once. Bounded payloads are validated against immutable JSON Schema versions, deduplicated by event id, and committed with an outbox row before the worker sees them.
When, if, then, stored as data. Conditions use all, any, exists, eq, neq, gt, gte, lt and lte; actions award XP, award points or log. Every published version stays readable for audit.
Copy a UTC window into a rule version to run a weekend bonus without a deploy. Campaigns and goals measure a bounded activity by event and unique-user counts.
Cumulative XP thresholds name levels. Missions track a target count, achievements unlock after a required count, and streaks read active UTC days for any event type.
Run loyalty points, coins and credits side by side. Each has an append-only ledger with expiring lots, atomic spending and conversion at a versioned rate.
Free or paid rewards, reservations, idempotency headers sent to HTTP providers, attempt history, and reconciliation for outcomes that are still unknown.
The server scopes every request to one environment, such as sandbox or production, so tests never touch live balances. Integration keys are hashed, shown once, and can be rotated or revoked.
A versioned REST contract with an OpenAPI description. Any HTTP client works from your backend; there is no SDK to adopt and no widget you must ship.
Goals, campaigns, metrics, funnels, retention cohorts, behavioural segments and experiment reports measure outcomes. They describe what happened; rules decide what happens.
Expiring hashed sessions, role-based console access, an append-only audit stream, rate limits, request ids, Prometheus metrics and a diagnostics snapshot of the pipeline.
The same loop, six genres. Every recipe is a real rule shape from the scenario cookbook.
order.completed{"eq": ["$.customer_order_number", 2]}
→ award_points loyalty 100+100 loyalty, once per order
The rule reads the payload. Your order service counts purchases and sends the number as a trusted field.
A simulation of MotifEngine’s event, rule, ledger and redemption semantics, running in your browser. Nothing is sent to a MotifEngine API, and your run is stored only in this browser.
Once. Your backend sends events over REST with an environment-scoped key. After that, currencies, levels, missions, achievements, rewards and automations are configured in the console.
No. MotifEngine is API-first: you design the player-facing interface and read profiles, balances, missions, achievements and progression from the API.
No. XP is progression and is never spent. Point currencies are spendable balances with their own ledgers, expiration and conversion rates.
The redemption stays in delivering and its points stay reserved. A provider status check or a retry with the same redemption id settles it; only a confirmed failure releases the points.
MotifEngine is open source, and you can run the full stack locally with Docker Compose. Public pricing has not been set.
Create a workspace, register your first event, publish a rule. Your players are already waiting.
Or run the whole stack locally: make dev-docker
MotifEngine runtime · power-on self test