coss.com

Email and webhooks for platforms.

coss.com gives multi-tenant platforms email sub-accounts per customer, webhooks to customers with a hosted portal, budgets, an audit log and SSO.

Read the docs

The problem

A platform whose customers send email or receive webhooks carries their mistakes unless each one is kept apart.

When a website builder, CRM or store builder sends email for its users, one user's bounced list or phishing campaign can pause sending for every other user on the same account. When the same platform sends webhooks to its customers, it ends up building endpoint management, signing, retries, a delivery log and a settings page for each customer to manage it all.

coss.com keeps customers apart and does the delivery work: email sub-accounts give each customer their own domains, reputation, quotas and suppressions; Hooks delivers your webhooks to your customers with a hosted portal; and the platform and security features (budgets, the audit log, SSO) let your team run it.

How it works

One sub-account and one Hooks application per customer, both addressed by your own id for that customer.

// When a customer signs up: a sub-account for their email, an application for their webhooks.
await ...({
  : "Acme Bakery",
  : "user_8812",
  : { : 5000 },
});
await ...({ : "Acme Bakery", : "user_8812" });

// Their own domain, with its own sending reputation at the mail provider.
await ..({ : "acmebakery.com", : "user_8812" });

// Send email for them...
await ..({
  : "user_8812",
  : "Acme Bakery <orders@acmebakery.com>",
  : "customer@example.com",
  : "Your order is ready",
  : "<p>Come and pick it up.</p>",
});

// ...and webhooks to them, delivered to every endpoint they registered.
await ...({
  : "user_8812",
  : "order.ready",
  : { : "ord_1042" },
});

// Let them manage their endpoints in the portal.
const { :  } = await ...({ : "user_8812" });
// Redirect to session.url, or embed it in your settings page.

Read more in email for platforms, Hooks and the portal.

What platforms get

Isolation per customer, delivery you don't build, and the controls a team needs to run it.

A sub-account per customer

Each sub-account has its own domains, its own SES tenant, quotas you set, a suppression list and stats. Every call accepts its id or your own uid, and its emails and webhook events carry its subaccount_id.

Reputation kept apart

A sub-account's bounce and complaint rates are measured on their own. At the suspension threshold, or when content screening blocks one of its emails, it pauses alone, and subaccount.* webhooks tell you.

Webhooks to your customers

Hooks sends each event once to an application and delivers it to every subscribed endpoint, signed, retried for about a day and logged. Failing endpoints are disabled after 5 days, and missed deliveries can be recovered.

A portal you don't build

Customers add endpoints, choose event types, roll secrets, browse deliveries and retry them in a portal on its own domain. Embed it on origins you allow, with your name, accent color and theme.

Budgets and spend

The Spend page splits usage by project, environment, API key and member. Monthly budgets on a project, a key or a member refuse live sends from that source once spend goes over.

Audit log and SSO

One audit log records who changed what, from the dashboard, the API or the portal. Single sign-on (SAML, OIDC) and directory sync (SCIM) manage your team's access.

Specifications

Limits that matter when you run many customers. The docs list each one in context.

Domains per sub-account
10, up to 5 awaiting verification
Sub-account stats
up to 45 days, per day
Hooks applications per environment
100,000
Endpoints per application
50
Hooks delivery attempts
8 over roughly a day
Hooks payload size
256 KB
Portal session lifetime
at most a day
Budget alert thresholds
80% and 100% by default
Sub-accounts on plans
Scale and Enterprise
SSO on plans
Scale and Enterprise

Questions

How do I send email on behalf of my customers?
Create an email sub-account per customer with coss.email.subaccounts.create() and name it with subaccount when you send. Each sub-account has its own domains, sending reputation at the mail provider, quotas, suppression list and stats.
What happens when one of my customers sends spam?
Only that sub-account is paused. Its bounces, complaints and blocked content are measured on their own, and its live sends are refused with subaccount_paused until you reinstate it, while your other sub-accounts keep sending. Your organization's own reputation still counts everything they send.
How do I send webhooks to my own customers?
Use Hooks. Create an application per customer, register your event types, and send each event once with coss.hooks.messages.send(). coss.com delivers it to every endpoint that customer registered, signed and retried for about a day.
Do I have to build a UI for my customers' webhook endpoints?
No. Hooks includes a portal on its own domain where a customer adds endpoints, picks event types, reveals and rolls secrets, sees every delivery and retries them. Create a portal session from your backend and redirect to it or embed it in your settings page.
Can I cap what each project or API key costs?
Yes. Owners set monthly budgets per project, per API key and per member on the Spend page. Once spend goes over a budget, live sends from that source are refused until the next month or until an owner raises the budget, and everything else keeps working.
Which plans include sub-accounts and single sign-on?
Live sub-accounts, SSO and directory sync are included in the higher plans, and sandbox sub-accounts are free on every plan so you can build the integration first. The pricing page lists which plan includes what.

The products

One key, one SDK, one log for all of them.

Build it this afternoon.

Hand your coding agent this prompt, then pick the parts you need:

Add coss.com to this project: read https://coss.com/llms.txt, get a development key with `npx coss-cli init --agents`, and build and test with it.

Pricing