Search Documentation
Search across all documentation pages
Email Notifications

Email Notifications

Transcodely sends email in two kinds, and the difference is the whole page:

  • Optional emails — the ones that exist to be useful. Budget alerts, usage and exposure reminders, payment-method reminders, data-retention warnings. Every one of these has a switch, and you can turn it off in a click.
  • Service notices — the ones that are part of your account. A payment failed. An invoice is ready. A member was added. An API key was created. A webhook endpoint was disabled. These are always on.

There is no third kind. We do not send marketing email to your billing contact.

Where they go

All of it goes to your organization’s billing email, set on Settings → Organization. That is one address per organization, not one per member — so the person who receives budget alerts is the person on that line.

If no billing email is set, these emails have nowhere to go and are simply not sent.

Turning optional emails off

Two ways, and they do exactly the same thing:

  1. Settings → Notifications in the dashboard. Every email we send is listed there — optional ones with a switch, always-on ones marked as such — with a one-line description of when each is sent. Choose, then Save; nothing is saved until you do.
  2. The unsubscribe link in the email itself. Every optional email carries one, in the footer and in the List-Unsubscribe header your mail client may surface as its own “unsubscribe” button. Following it turns off that one group of emails, for that organization, and nothing else. The link never expires.

The preference is per organization and per group, not per email and not per person. Turning off budget alerts turns off every email in that group, for everybody who reads that billing address, until someone turns it back on.

A brand-new kind of optional email starts out on, like everything else. Turning off one group never silently signs you up for or out of another.

What “always on” means

Service notices are not marketing, and they are not a preference we ask you about: they are how an account tells you something about itself. An invoice that failed to charge, a suspension, a key that was created, an endpoint that stopped receiving — you would be right to be angry if a switch somewhere had quietly stopped those from reaching you.

So they have no switch, they carry no unsubscribe link, and an unsubscribe link from an optional email can never turn them off. The Notifications page still lists them, because “which emails does this company send me” deserves a complete answer.

Undeliverable addresses

If your billing address hard-bounces — the mailbox does not exist, the domain does not resolve — we stop sending to that address rather than keep hammering it, including service notices, because a mail nobody can receive is not a notice. The fix is to correct the billing email on Settings → Organization; a new address starts clean.

Marking our email as spam has the same effect for optional email.

No API for this

Notification preferences are a dashboard setting, not an API surface: they are read and written by a signed-in organization member, and API keys are refused. If you want notifications your software can act on, use webhooks — that is the machine-facing half of this, and it has its own event catalog, signing, and retry behavior.

  • Budgets — the monthly figure that produces budget alerts, and what changing it does to them
  • Spend Limits — the per-app cap that blocks, and notifies over webhooks rather than email
  • Payment Failures — the dunning emails, which are service notices
  • Webhooks — machine-readable notifications for your software