Automations & Notifications

Every email Cobuntu sends on your behalf is driven by an automation — a small rule that listens for something happening in your community and takes an action in response. Automations are how membership confirmations, ticket receipts, payout alerts, and reminders go out without anyone touching a keyboard.

The model has three properties that are worth understanding up front, because together they give you full control over your community's communications:

1. Every email is brand-customizable. Emails render with your community's logo, colors, sender name, and reply-to address. Many also expose editable copy in the admin app, so you can rewrite subject lines and body text to match your voice.

2. Every email is optional. Cobuntu does not send transactional email as a side effect of an action. An email goes out only if an automation is configured and running for that touchpoint. Turn the automation off and the email simply stops — nothing else breaks.

3. Every email is mirrored by a public webhook. For every customer-visible email touchpoint, Cobuntu emits an equivalent webhook event. This means you can switch off Cobuntu's email for any touchpoint and drive your own system from the webhook instead — send the message from your own ESP, push it into your CRM, fire a Slack alert, or do nothing at all. The webhook fires whether or not the email is enabled, so your downstream systems keep working independently of what Cobuntu mails.

Account & security emails are separate

This page is about community notifications — the messages your community sends to its members and buyers. They are distinct from account emails (password resets, email verification, sign-in security). Account emails are sent by Cobuntu at the platform level for every user: they always send, they aren't community-branded, and they have no automation or webhook to configure. Everything below applies only to community notifications.

How automations work

An automation is a trigger paired with one or more actions:

• Trigger — the thing that happens in your community: a member is approved, a ticket is purchased, a payout fails, an event reminder window opens.
• Action — what runs in response: most commonly send a branded email to the relevant recipient.

A new community ships with a default set of automations already installed and enabled by default, so the expected emails (welcome messages, receipts, reminders, payout and dispute alerts) work the moment you go live. A few sensitive automations — like removal and ban notices, and the member digest — install in a draft state and only begin sending once a community leader reviews and activates them.

You manage all of this in admin → Automations.

Turning an email off and using the webhook instead

A common pattern: you already have your own email infrastructure and want Cobuntu to stop sending a particular message, while you take over that touchpoint from your own stack. Here's the flow:

1. Subscribe to the webhook. Go to admin → Integrations → Webhooks, create (or edit) a webhook pointed at your receiver URL, and select the event for the touchpoint you want to own — for example member.approved or event.ticket.purchased. (See Set up a webhook.)
2. Disable the matching automation. In admin → Automations, find the automation for that touchpoint and turn it off. Cobuntu stops sending that email.
3. Drive your own action from the delivery. Your receiver now gets the webhook every time the touchpoint occurs, with a full payload (see the Event catalog). Render and send your own email, update your CRM, or trigger any other side effect.

Because the webhook is independent of the email automation, you can also do both — keep Cobuntu's branded email and subscribe to the webhook for analytics or syncing — or neither, if a particular touchpoint isn't relevant to you.

Idempotency & ordering. Webhooks are delivered at-least-once and without ordering guarantees. Always dedupe on the delivery id and rely on payload timestamps, not arrival order. See Delivery guarantees.

Notification catalog

The table below lists every email Cobuntu can send, who receives it, what triggers it, and the public webhook event you subscribe to in order to own that same touchpoint yourself.

A few notes that apply across the table:

• Default vs. draft. Most automations are enabled by default. Removal/ban notices and the member digest install as drafts and send only after a leader activates them — these are marked below.
• Purchase and refund touchpoints have both an umbrella event and channel-specific events. For purchases, sale.completed is the umbrella webhook that fires on every paid checkout; the channel-specific events (event.ticket.purchased, product.purchased, subscription.purchase_receipt) own the buyer-facing email for their respective product class. For refunds, refund.issued is the buyer-facing umbrella; event.ticket.refunded and product.refunded are the channel-specific buyer events. Subscribe to the umbrella when you want one stream for all sales or refunds; subscribe to the channel-specific event when you only care about one product class. Pick a single owner per touchpoint to avoid sending a buyer two messages for one action.

Broadcasts and digests are campaign sends rather than reactive transactional emails. A broadcast is composed and sent by a leader on demand; the broadcast.sent webhook fires after the campaign goes out, as a completion signal. The member digest is a scheduled roll-up that a leader opts into.

For full webhook payloads, signature verification, retry behavior, and the complete event reference, see the Webhooks documentation and the Event catalog.