Notifications#

Laver notifies you about eight things. Each one can arrive in the app, by email and as a push notification, and you control the three independently.

Moved by somebody else covers every move of your ticket into another column that you did not make yourself: a colleague dragging the card, an automation rule sending it on, an agent with an API key walking it through the board, and a ticket landing in the column tagged for merged pull requests. Your own moves never notify you — you were there — so the one person a move is never announced to is whoever made it.

A move a person made shows their name. A move nobody made shows as coming from Automation rather than from the person the rule runs as or whose key the agent holds.

The two Deployments events are reported by your build pipeline rather than produced inside Laver — see Deployment notifications. Until a pipeline reports one, they simply never fire.

Choosing what reaches you#

My profile → Notifications. Every event has an in-app tick, an email tick and a push tick, and they all start on.

Preferences are stored sparsely: a record exists only where you have changed something. That has one deliberate consequence — an event added in future starts switched on for everyone, rather than being silently muted for anyone who has never opened the screen. If you want it off, turn it off.

Turning a channel off stops it being produced at all, so muting an event does not quietly accumulate a pile of unread notifications you never see.

Emails#

An email carries the ticket, who did the thing, and a link straight to it.

Each one has an unsubscribe link, and mail clients that support RFC 8058 show their own unsubscribe button for it.

The unsubscribe link is one decision, not one category. Clicking it stops all optional email — notification email and billing/product updates together. Somebody clicking "unsubscribe" means stop the optional email, not stop this kind and keep the rest arriving. You can resubscribe from the same link.

What it does not stop. Security notices and the non-payment sequence ignore it by design: a password change or a failed payment reaches you whatever your preferences say. Those are not marketing, and losing a customer silently because they muted an invoice is worse than an unwanted email.

If you want to keep billing email but stop ticket email, use the per-event email ticks in your profile rather than the unsubscribe link.

Push#

Push notifications arrive on the device rather than in the app, so they reach you with Laver closed.

There are two switches and you need both. The Push column above decides which events may buzz your account at all. Send notifications to this device, underneath the table, decides whether the browser you are reading this in is one of the places they arrive — so turning a device off does not lose your per-event choices, and a device you no longer use stops buzzing without touching them.

The browser asks for permission the first time you switch a device on. If you refuse, Laver cannot ask again — it has to be allowed in that browser's site settings before the switch will work.

On an iPhone, add Laver to your home screen first. iOS only delivers web push to an installed app, so the switch reports that the browser cannot show notifications until you have.

On your desktop#

Show notifications on this device while Laver is open, under the push switch, hands each new notification to your operating system as it arrives — so it appears in the Windows 11 notification centre, the macOS Notification Centre or your desktop's own tray, next to everything else that notifies you. Clicking one opens the ticket or page in the Laver tab you already have.

It is a switch per browser, like the push one, and the browser asks for the same permission the first time you turn it on. Nothing has to be configured on the server for it.

Push and this are not the same switch, and both can be on. Push reaches you with Laver closed; this only works while a tab is open, which is exactly the stretch where a background window otherwise tells you nothing. A notification that arrives through both is shown once, not twice.

Two deliberate limits: notifications that were already unread when you opened the tab are not shown — only what arrives afterwards — and a burst shows the three newest rather than one alert per row. The rest are in the bell.

Project summaries#

Everything above is about one thing happening. A project summary is the other shape: a scheduled email about a whole board.

My profile → Project summaries. Every board you can open is listed with a frequency — Never, Daily, Weekly or Monthly — and every one of them starts at Never. Pick a cadence and the sections appear underneath it:

A few things follow from the design and are worth knowing:

• The first email is one whole period away. Turn on a weekly summary today and the first one arrives next week, covering the week — not an empty one within the minute.
• A quiet period sends nothing. If nothing was filed, finished or fell overdue, there is no email. A daily summary that says "no change" every morning teaches you to filter the address.
• Changing which sections you want does not move the schedule. Changing the frequency does, and restarts the clock from now.
• It is per person and per board. Two people watching the same board choose their own cadence and their own sections, and neither can see or change the other's.
• It shows what you can see. A guest never gets an internal ticket named in a summary, and losing access to a board stops its summary immediately — checked when the email is sent, not when you subscribed.
• Missing a run does not pile up. If summaries could not be sent for a week, you get one email covering the gap rather than seven.

Each summary carries the same unsubscribe link as everything else, plus a link back to this screen — stopping one board's email should not mean silencing every optional email Laver sends.

By API#

curl https://api.laver.app/profile/notification-preferences \
  -H "Authorization: Bearer $SESSION_TOKEN"

Returns every event with its label, its group, and the state of each channel, so a client can render the screen without hard-coding the list.

PUT the same path to change them. This is a session-token route — an API key cannot read or change someone's preferences.

Project summaries work the same way:

curl "https://api.laver.app/profile/summary-emails?workspace_uuid=$WORKSPACE" \
  -H "Authorization: Bearer $SESSION_TOKEN"

Returns the sections and cadences on offer, the boards you can subscribe to, and your current subscriptions. PUT /profile/summary-emails with { board_uuid, frequency, sections } sets one — at least one section — and DELETE /profile/summary-emails/<board_uuid> stops it. These are session-token routes too, so an agent cannot sign anyone up for email.

What there is not#

• No per-event digest. Notification emails are sent per event, never batched. The project summaries above are a separate, scheduled email about a board, and they do not replace or delay anything in the table at the top.
• No send hour or timezone. A summary arrives at roughly the time of day you set it up, in UTC.
• No desktop app. The desktop notifications above come from the browser tab Laver is open in; there is nothing to install.
• No per-board or per-workspace override. A preference is per person, across everything they can see.