Is this similar to how Stripe uses events?

Yes. The mental model is similar — your system produces domain events, consumers (like else.events) react to them. Stripe webhooks fire events; you fire events to else.events.

Do I have to migrate all my emails at once?

No. You can start with one event type (e.g. invoice.payment_failed) and migrate others incrementally. Your existing email sending can continue in parallel.

What if my event schema does not match what else.events expects?

else.events adapts to your payload schema. You define the event shape; rules and templates reference the fields you choose.

Can I send to multiple recipients from one event?

Yes. Multiple rules can match a single event and each can send to a different recipient or template.

An event-based email API — not just another send() call

Instead of calling sendEmail("payment-failed-template", user) for every case, you fire an event. else.events matches rules, picks the template and delivers.

Try the event API See the full email API

The sendEmail() pattern does not scale with SaaS complexity

Every email requires a direct call with a template name

sendEmail("payment-failed-pro-plan-de", user) — you are encoding routing logic in your function call.

Adding a locale or plan variant means a new call site

Supporting a new language or plan tier means finding every sendEmail() in your codebase and branching.

Your app knows too much about email templates

Your billing service should not know which template handles German Pro-plan payment failures. That is routing logic, not billing logic.

No central audit trail

Multiple send() call sites make it impossible to see all emails a user received from a single place.

Fire an event. else.events decides the rest.

An event-based email API inverts the model. Your app describes what happened. else.events figures out what to send.

One call site per domain event

POST invoice.payment_failed once. Rules and templates handle every plan, locale and tenant variant.

Routing logic lives in the platform, not in your app

Your billing service does not know which template fires. It just knows a payment failed and fires the event.

New variants without touching your app

Add a new plan tier or locale? Add a rule and a template in the dashboard. Zero code change.

Full event history

Every event, every matched rule, every email delivery — logged together with domain context.

Event-based API vs traditional sendEmail() pattern

Capability	Event-based (else.events)	sendEmail() pattern
Adding a locale variant	Add a rule + template in dashboard	Find every call site, add branch
New plan tier	Add a rule in dashboard	New conditional in application code
Routing logic location	Platform rules, visible to all	Buried in application code
Audit trail	Centralised per event	Scattered across services
Template change without deploy	Yes	No

The event-based model reduces coupling between your domain logic and your email delivery infrastructure.

Frequently asked questions

Is this similar to how Stripe uses events?: Yes. The mental model is similar — your system produces domain events, consumers (like else.events) react to them. Stripe webhooks fire events; you fire events to else.events.
Do I have to migrate all my emails at once?: No. You can start with one event type (e.g. invoice.payment_failed) and migrate others incrementally. Your existing email sending can continue in parallel.
What if my event schema does not match what else.events expects?: else.events adapts to your payload schema. You define the event shape; rules and templates reference the fields you choose.
Can I send to multiple recipients from one event?: Yes. Multiple rules can match a single event and each can send to a different recipient or template.

Replace sendEmail() with an event

Fire your first domain event. Let else.events handle routing, rendering and delivery.

Free during public beta
Migrate incrementally
No SDK required