---
title: "Everything Palumb supports."
url: "https://palumb.com/features"
description: "Multi-step workflows, durable waits, waiting on an external signal, sends on a schedule, digests, fan-out, retries and idempotent replay, through your own provider."
---

# Everything Palumb supports.

Every capability, with what it does. Scan this page when you need to know whether Palumb covers your case, and [the use cases](/use-cases/) when you want to see them working together.

Multi-step workflows

Branch and loop between sends, in your own language, with no builder in the middle.

Any template engine

Keep the engine you already use: MJML, React Email, Handlebars, or a plain string. Palumb never renders; it only delivers what you hand it.

Durable waits

Hours or days between steps. A crash or a deploy does not lose them.

Waiting on a signal

Pause until something happens outside, or until the timeout fires.

Sends on a schedule

A run gathers over a window and closes on a calendar instant your own code computes. Nothing of ours is armed, and the run opens the next window itself.

Digests

Each event becomes one item in a window that fills up inside the run; when the window closes, every item goes out in one notification.

Fan-out

Subscribe a recipient to a topic once; every trigger on that topic reaches everyone still on it, each with their own run.

Retries with backoff

What fails is tried again, on a schedule that backs off.

No double send on replay

A step that already sent is not run again, and a retry carries the same Message-ID.

Every attempt recorded

Accepted, failed or bounced, with the reason.

A REST API, spec published

Subscribers, topics and triggers over plain HTTP, described by an OpenAPI document. No SDK required, in any language.

A dashboard for what happened

Subscribers, topics, and delivery reports. Workflows are not drawn here; they live in your repository.

An MCP server

Point your own agent at the same API: subscribers, topics, triggers, usage. It runs on your machine, on your key.

Any sending provider

Email, SMS, Telegram, Slack and push (web and mobile), each on your own sending provider. Never a shared pool.

Signed both ways

Palumb signs the call, your Bridge signs the answer. Fail-closed.

## See them as working code

A list tells you what exists. The use cases show the same capabilities solving one problem at a time, in the workflow you would actually write.

[Use cases](/use-cases/)

Everyone who joins gets in, and it costs nothing. Your invite goes out when the beta opens.

[Join the beta](/waitlist/)