Features

Send from the browser without an abusable secret

Q: Is it compatible with existing EmailJS code?

Yes — the endpoint ( /api/v1.0/email/send ) and body shape ( user_id , service_id , template_id , template_params ) match, so migrating is changing the endpoint and the key, not the code. See the migration comparison .

Q: What stops junk data in template variables?

Each template declares a typed variable_schema — string , email , number , boolean , with required , maxLen , and enum constraints. Requests with unknown, missing, or oversized fields are rejected before admission.

A browser SDK where the public key is safe by structure: the recipient always comes from a server-stored template, and no request field can change it.

The contact-form problem, solved structurally

You can send email from frontend code with @email-fast/browser and no backend at all. The key you ship in the page is public by design and safe by structure: a browser SDK with EmailJS-compatible endpoints — the recipient always comes from the server-stored template, never from the request, so a public key in your frontend can't be abused to spam arbitrary addresses. Rate limiting is on top of the safety story here, not the whole of it.

How it works

Create a template server-side. Its recipient — you, your support inbox — is fixed there. Nothing in a browser request can choose or change it.
Give the template a typed variable_schema (string, email, number, boolean, with required, maxLen, enum). Requests with unknown, missing, or oversized fields are rejected.
Allowlist your origins for the key and set per-key rate caps.
Optionally enable a visitor auto-reply — "we got your message" — capped per visitor per day.

The evidence

The whole request, EmailJS-shaped

// POST /api/v1.0/email/send
{
  "user_id": "your_public_key",
  "service_id": "default",
  "template_id": "contact_form",
  "template_params": { "name": "Ada", "message": "Hello there" }
}

Notice what's missing: a to field. There isn't one, and there is nothing to substitute for it — the recipient lives in the template, on the server. template_params is validated against the template's typed schema before admission.

Honest limits

A deliberately narrow lane

This lane is for contact forms, feedback, and lead capture — mail that comes to you. Arbitrary recipients require the REST API and a server, on purpose. Origin allowlists stop browsers, not curl — any non-browser client can forge an Origin header — which is exactly why recipient pinning and per-key caps exist: the allowlist cuts noise, the structure prevents harm. And rate caps bind honest traffic spikes too; raise them deliberately, not reactively.

Where to go next

Five-minute setup in the browser quickstart. Collecting subscribers rather than messages? That's signup forms. The developer door covers the rest of the surface, and the comparison is the honest read if you're deciding whether to switch.

Questions, answered plainly

Can someone take my public key and spam people?

No. The recipient is pinned in the server-stored template; no field in any request can select an address. A stolen key can only send your own templates to you, within your rate caps and origin allowlist.

Is it compatible with existing EmailJS code?

Yes — the endpoint (/api/v1.0/email/send) and body shape (user_id, service_id, template_id, template_params) match, so migrating is changing the endpoint and the key, not the code. See the migration comparison.

What stops junk data in template variables?

Each template declares a typed variable_schema — string, email, number, boolean, with required, maxLen, and enum constraints. Requests with unknown, missing, or oversized fields are rejected before admission.

Can I send visitors an automatic confirmation?

Yes — an optional visitor auto-reply, capped per visitor per day, so a reply loop or a malicious script can't turn your form into a mail cannon.