Digest notifications: one message for a burst of events.

A digest step sits in a workflow between the trigger and the channel steps. The first event for a subscriber opens a digest. Events that arrive for the same subscriber, in the same workflow, while it is open join it instead of running the rest of the workflow themselves. When the window ends, the steps after the digest run once, with every collected event available to their templates.

• steps.<step id>.events: the collected events, oldest first. Each has an id, a time and the payload its trigger sent.
• steps.<step id>.eventCount: how many events the digest holds.
• The toSentence and pluralize Liquid filters turn those into copy. The editor's variable picker offers them as sentenceSummary and countSummary.

Every step after the digest sees the same events: an email, an in-app message, an SMS, a push or a chat message can each summarise the batch in its own words.

In the workflow editor, a digest step's Digest window has two tabs, Regular and Scheduled. A look-back digest is a Regular digest with its Start digest option changed.

An earlier event has gone out once it was sent on its own, or once the digest it opened was sent. Events still waiting in an open digest don't count, and neither do events that joined one.

Look-back suits alerts where the first one matters: a quiet user gets the first comment immediately, and only a burst is batched. Scheduled suits a daily or weekly summary that should arrive at the same local time for everyone.

Events are always digested per subscriber. Group events by adds one payload variable to that key, stored as {{payload.<name>}}, so one subscriber gets a separate digest per post, project or ticket instead of one digest for everything.

The example below groups by {{payload.postId}}: comments on two different posts produce two emails, each about its own post.

The workflow comment-activity has two steps: a digest step with the step id digest-step, a Regular window of 30 minutes grouped by {{payload.postId}}, then an email step. Your backend triggers the workflow once per comment:

// npm install @notiflyio/api@0.1.26
import { Notifly } from "@notiflyio/api";

const notifly = new Notifly({ security: { secretKey: process.env.NOTIFLY_SECRET_KEY } });

// One trigger per comment. The digest step decides what the post's owner receives.
await notifly.trigger({
  workflowId: "comment-activity",
  to: { subscriberId: "user_123", email: "owner@example.com" },
  payload: { postId: "post_42", authorName: "Ada" },
});

The email step's subject and body read the digest's outputs through the two filters:

Subject: {{steps.digest-step.events | toSentence: 'payload.authorName', 2, 'other'}} commented on your post

You have {{steps.digest-step.eventCount | pluralize: 'new comment', 'new comments'}}.

Ada, Grace and Linus comment on the same post at 09:00, 09:10 and 09:20. With the Regular 30-minute window, Ada's comment opens the digest and the other two join it. The post's owner receives one email:

• 09:30: subject "Ada, Grace, and 1 other commented on your post", body "You have 3 new comments."

Switch Start digest to When events repeat within 30 minutes and the same three comments arrive differently. Ada's comment has no earlier one, so it is sent at once. Grace's arrives within 30 minutes of Ada's, which has gone out, so it opens a digest. Linus's comes 20 minutes after Ada's and joins that digest, sent 30 minutes after Grace's:

• 09:00: subject "Ada commented on your post", body "You have 1 new comment."
• 09:40: subject "Grace and Linus commented on your post", body "You have 2 new comments."

Timing matters. Had Linus commented at 09:35 instead, Ada's comment would be more than 30 minutes old and Grace's still waiting in its digest, so neither would count, and Linus's comment would go out on its own:

• 09:00: subject "Ada commented on your post", body "You have 1 new comment."
• 09:35: subject "Linus commented on your post", body "You have 1 new comment."
• 09:40: subject "Grace commented on your post", body "You have 1 new comment."

The longest window a digest step can hold events for depends on the plan. It is checked when you save the workflow, and for a scheduled digest it covers the gap between two runs.

Each trigger counts as one event on your plan, whether or not a digest folds it into another message: a digest reduces the messages your subscribers receive, not the events you send. The pricing page lists each plan's monthly events.

• Workflows: how workflows are built in the editor and triggered with one API call.
• In-app inbox: the feed a digest can write one summary to instead of many messages.
• REST API: triggering workflows over plain HTTP, with authentication and errors.