How it works
notific.me has five core pieces. Everything else is built on top of them.
| Piece | What it is | Example |
|---|---|---|
| Event | Something happened | deploy.ok, lead.new, container.die |
| Policy | Who should know, when, how urgently and at which level | “Everything from AI agents needs level 2” |
| Card | How the notification looks | Summary, declarative card |
| Action | What can be done from it | Approve, pick an option, open a dashboard |
| Reply | The signed answer that goes back | { question_set_id, version, answers, signature } |
The whole cycle
Section titled “The whole cycle”- Your system sends an event (
POST /v0/events) or a question set (POST /v0/asks) with a service token. It can also post any webhook to an incoming hook, or an AI agent can use the MCP server. - The ingest API validates the payload against the open protocol, merges duplicates by
dedup_key, and makes retries safe with idempotency keys. - The policy rules of the workspace decide what happens:
notify,digest,suppressorescalate. - A notification is created for each recipient, carrying a summary, a card and, for questions, the question set.
- The person receives it on the app, the web app or a push notification.
- The person decides. The level defines what that takes: a tap, an unlocked device, biometrics or a 2FA code, and possibly a quorum.
- The server accepts the answer atomically: one answer wins, and the reply plus the webhook to your system are saved in the same transaction (transactional outbox), so a decision is never lost.
- The signed reply goes back to your system: as a webhook to
callback_url, signed with Ed25519, or as the result of theask()call that is long-polling.
Policy rules
Section titled “Policy rules”Rules are checked in order, and the first one that matches decides. When none matches, the workspace default applies. Quiet hours can turn notify into a digest (or suppress it) below a minimum severity. Learn more in Rules and policies.
The life of a question
Section titled “The life of a question”ask() in the SDK does both steps for you: it creates the question set and long-polls until it is answered or times out. See Questions and answers.
Decision levels
Section titled “Decision levels”The service sets the minimum level in ask(). The workspace can raise it, never lower it. The highest level among the questions applies to the whole set, and one signature covers all the answers.
Signing with the 2FA code
Section titled “Signing with the 2FA code”Not every device has a fingerprint reader, and the browser has no biometrics. A person who enables two-step verification (an authenticator app with TOTP codes) can sign level 2 and 3 decisions with the 6-digit code.
- Level 3 always asks for a new code, for every action.
- Level 2 can use a 2FA window the person chooses in their account (off, 5, 15, 30, 60, 120 or 240 minutes). After a valid code, that session can sign level 2 decisions without typing the code again. With 50 pending approvals, nobody wants to type 50 codes.
- Biometrics is always one prompt per decision.
- Level 4 (quorum) still requires the app with biometrics.
Delivery
Section titled “Delivery”- App open: the WebSocket gateway delivers in tens of milliseconds.
- App closed: the push relay sends through APNs (iOS), FCM (Android) or Web Push for the installed PWA. Web Push is encrypted end to end, so it can show the title and summary.
- When the app opens again, it syncs incrementally from a cursor, so nothing is missed.
See App, PWA and push.