Skip to main content

Digest Batching

Automated journeys are great at reacting to everything — and that's exactly the problem. A busy subscriber can trip three journey steps in an afternoon and get three separate pings. Digest batching lets a journey step say: this update matters, but it doesn't need to interrupt anyone. Digest messages queue quietly per subscriber and arrive as one bundled notification.

Digest batching is available on Growth plans and above, on journey Send steps. Campaign and one-off sends always deliver immediately.

The rule, in full​

Like Smart Channel, digest batching is a published heuristic — no black box:

  1. Per-step opt-in. Each journey Send step chooses its delivery priority: immediate (the default — today's behavior) or digest. Nothing is digested unless the step's author said so.
  2. Transactional never digests. Order confirmations, password resets, receipts — anything transactional always delivers immediately, enforced at authoring and again at delivery.
  3. A digest message queues per subscriber instead of delivering, holding the step's title, body, and channels as a snapshot.
  4. The queue flushes as one bundled notification when the first of three things happens:
    • 3 updates are waiting — enough to be worth an interruption;
    • the subscriber's best send hour arrives (from their own 90-day engagement history) with anything waiting;
    • the oldest update has waited 24 hours — nothing waits longer than a day, ever.
  5. The flush is a real send. It goes through the same delivery pipeline as everything else — sending quota, consent, and quiet hours all apply. It delivers on the union of the queued items' channels.
  6. One update arrives as itself. A digest of one keeps its original title and body — no "1 update" framing. Bundles of two or more read "N updates" with one line per item.

Turning it on​

In the journey builder, open a Send step and set Delivery priority to Digest — bundle quietly. Via the API, set the step's priority field:

{
  "id": "s2",
  "type": "send",
  "send": {
    "channel_ids": ["ch-push"],
    "template_id": "…",
    "priority": "digest"
  }
}

priority accepts immediate (default) or digest. Saving a journey with a digest step on plans below Growth returns 403 with {"error": "feature_not_available", "feature": "digest_batching"}.

Reading the results​

The journey canvas shows a digest readout when the journey has queued anything: queued (waiting for a bundle) and delivered bundled counts. The same numbers ride GET /api/v1/journeys/{id}/stats as an optional digest object:

{ "digest": { "pending": 12, "flushed": 340 } }

What digest batching deliberately does not do​

  • No lost messages. If queueing fails for any reason, the message delivers immediately instead — batching fails open, always.
  • No transactional batching, regardless of the flag.
  • No configurable K. The 3-update threshold and 24-hour cap are fixed and published; if real demand for tuning shows up, it becomes a setting later.
  • No re-personalization at flush. The bundle renders from the enqueue-time snapshots.