How Plinth works

Four things to keep straight. Once you've got these, the rest is just URLs.

Workspace

Your team's account on Plinth. Holds your real provider keys, sealed in a vault.

Provider

An email rail you already pay for: Brevo, Resend, your in-house SMTP. Connect it once on /providers and Plinth seals the credential. The raw key never leaves the vault. Connect a second provider and Plinth treats them as a pool.

App

Anything that calls Plinth. Your website's transactional sender. Your marketing-newsletter cron. Your AI assistant in Cursor. A Python script. Each app gets its own API key, its own brand identity, and its own routing strategy — so marketing and transactional can ride different rails without forking your code.

API key

The bearer token an app uses to prove who it is. Looks like plinth_production_xyz…. Shown once when you create the app, then only as a hash in our database.

Here's every step, in order, for one emails.send_template call:

1. 1Your app says “send the welcome template to [email protected] with { firstName: "Ada" }.”
2. 2Plinth checks the API key — yes, this app belongs to your workspace, yes it's allowed to call emails.*.
3. 3Plinth looks at the app's routing strategy (single, round-robin, or random) and picks a provider from your pool — say, Resend.
4. 4Plinth checks the regulation buckets for Resend on this workspace. Daily quota OK? API rate limit OK? If not, fail over to the next provider in the pool. If everything's exhausted, the call fails with a clear error before any traffic leaves us.
5. 5Plinth opens the safe, reads your Resend key, renders the template against the app's brand identity, and calls Resend. Gets a message ID back.
6. 6Plinth writes a tamper-evident audit row (App X sent template “welcome” via Resend at 10:32) and a usage event. Returns the result to your app.

One email provider is fine until the day it isn't. The most common ways “the day it isn't” arrives:

• Free-tier daily quota exhausted. Brevo free is 300 sends/day. Resend free is 100 sends/day. Your one-provider setup silently drops everything for the rest of the day.
• API rate limit tripped. Resend caps at 10 req/s. A burst from a backfill kills your transactional flow with no backoff.
• Reputation drop on one IP / domain. You don't want to find out the morning of a launch.
• The provider has an incident. Status pages exist for a reason.

Plinth's answer is a per-app provider pool with a routing strategy. single is the default (one provider, like the products you're used to). round_robin rotates evenly so reputation builds across two rails. random uniformly samples — useful when you're A/B-testing inboxing across providers.

On every call, Plinth checks the regulation buckets before it dispatches. If the chosen provider would exceed its quota, the next one in the pool gets the send. The decision shows up in the audit row so you can review “why did this go through Brevo and not Resend” later.

Same key works on all four. Pick whichever fits the job.

{
  "mcpServers": {
    "plinth": {
      "url": "https://plinth.tools/mcp",
      "headers": { "Authorization": "Bearer ${PLINTH_API_KEY}" }
    }
  }
}

await fetch("https://plinth.tools/api/v1/call", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PLINTH_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "emails.send_template",
    arguments: {
      template: "welcome",
      to: "[email protected]",
      vars: { firstName: "Ada" },
    },
  }),
});

# Customer support agent (Python)
template = await call("emails.compose_template", {
    "goal": "Apologize for the outage on 2026-05-09 and explain credits.",
    "audience": "Pro tier customers in EU",
})
await call("emails.send_template", {
    "template": template["key"],
    "to": "[email protected]",
    "vars": { "credits_usd": 12 },
})

curl -X POST https://plinth.tools/api/v1/call \
  -H "Authorization: Bearer $PLINTH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"emails.send_template","arguments":{"template":"trial_expiring","to":"$RECIPIENT"}}'

You connect Brevo and Resend once on /providers. Then you create four apps — each with its own routing strategy and brand identity:

All four use the same Brevo and Resend keys. None of them sees the plaintext. Each gets the brand it should — App B's newsletter looks different from App A's receipts even though they live in one workspace.

A morning in the audit log might look like:

10:01  App A   emails.send_template     (welcome,  via resend)
10:01  App A   emails.send_template     (receipt,  via brevo)   ← round_robin
10:03  App C   emails.compose_template  (apology, en-US)
10:03  App C   emails.send_template     (apology,  via resend)
10:05  App B   emails.send_template     (newsletter, via brevo) ← single
10:05  App D   emails.compose_template  (welcome v2 draft)

You can revoke App D's key in one click without touching the others. App A keeps sending receipts. App B keeps shipping the newsletter. That's why you split apps even when they all do “send email” — different routing, different brand, different blast radius on revocation.

You have two URLs. Same key works on both. Same things happen behind the scenes. Pick by what your client speaks:

They're literally the same dispatcher behind two envelopes. That's why one app key works on both — pick whichever your client speaks and don't overthink it.

You don't configure any of this. Every send gets it for free: