Why Our Email API Won't Send Your Newsletter

When we built the Tricknowtech Email API, we made a decision that limits what customers can do with it: it only sends transactional mail. Order confirmations, receipts, password resets, shipping notifications, appointment reminders, account and security alerts — that's the list. No newsletters, no promotional blasts, no marketing sequences. This isn't a pricing-tier restriction we might lift later. It's enforced, and it's enforced by an LLM that checks every message before it goes out.

That's an unusual amount of infrastructure to put behind what sounds like a policy statement. The reason is that it isn't a policy statement — it's a condition of the infrastructure underneath the product.

The constraint comes from AWS, not from us

The Email API runs on AWS SES. Production sending access — the capability the product depends on — is granted on the condition that traffic stays genuinely transactional. That's an AWS SES production-access condition, not a rule we came up with and layered on top.

This matters because it changes what kind of decision "transactional-only" is. We didn't sit down and decide marketing email is a feature we'd rather not build. We built on infrastructure that only grants us the sending capability we need if we keep the traffic clean. Build a marketing-email feature into the product and we're not making a product tradeoff — we're jeopardizing the sending access every customer's receipts and password resets depend on.

Mixed traffic is a deliverability risk, not just an access one

There's a second, related reason, and it's about deliverability rather than access. Sending reputation is something mailbox providers track over time, and mixing promotional content into a stream that's supposed to be transactional is a well-understood way that reputation gets put at risk — and once it is, the effects don't stay confined to the message that caused them.

That's a bad trade for a product built around transactional mail specifically, because transactional mail is exactly the mail you can't afford to lose to a spam filter. A promotional email that lands in spam is a missed sale. A password reset or an order receipt that lands in spam is a support ticket, a lost login, a customer who thinks their payment didn't go through. Keeping the traffic strictly transactional is what keeps the deliverability guarantee meaningful for the mail that actually depends on it.

A written policy doesn't hold up at scale

The obvious cheaper alternative is a terms-of-service line — "transactional use only" — and trust customers to follow it. We didn't build the product that way, because a written policy only works if someone's enforcing it, and manual enforcement of a rule like this doesn't scale and doesn't apply consistently. Someone would have to spot-check sends, decide case by case whether a given email counts as transactional, follow up, and probably still miss most of the volume. Different reviewers would draw the line in different places. The guarantee would exist on paper and be aspirational in practice — which is worse than not making the guarantee at all, because customers would build on it assuming it was real.

What the automated check actually does

So instead, every send — templated or freeform — is checked by an LLM before it goes out, specifically to confirm it's genuinely transactional. Templates are reviewed once; once a template is approved, that approval is fast in practice, usually within seconds. Freeform sends don't get that one-time pass — there's no fixed template to have already vetted, so each freeform call is checked live, every time, before the message leaves.

The difference in review cadence isn't arbitrary — it matches where the risk actually sits. A template's content is fixed once it's approved, so one review covers every future send of it. Freeform content is different every time a customer's code calls the API, so there's no stable thing to have pre-approved — each call is new content and gets evaluated on its own. This is also why it has to be an LLM doing the check rather than a keyword filter: "your order has shipped" and "your order is 20% off this week" don't differ by a blocklist term, they differ by intent, and intent is what has to be classified on every call for the restriction to mean anything.

The boundary is the point, not a gap to apologize for

The honest consequence of all this: the Email API genuinely cannot be used to run a newsletter or a promotional campaign. That's not a current limitation we're working to lift — it's the boundary that makes the rest of the guarantee real. A customer who wants transactional email with reliable deliverability and one who wants to blast a discount code to a mailing list have different infrastructure needs, and building one product to serve both would leave neither with a guarantee worth trusting. Keeping the API scoped to receipts, resets, shipping updates, and account alerts — and checking every send to make sure it stays that way — is what lets us make a deliverability commitment for that traffic instead of a hedged one.

For a customer integrating the API, the practical shape of this is simple: send order confirmations, password resets, shipping notifications, appointment reminders, and security alerts, either through an approved template or freeform through the @tricknowtech/email SDK or the MCP server's send_email tool. Every one of those sends clears the same check — the one that keeps the sending domain's reputation, and the production access it depends on, intact for the mail that actually needs to reach the inbox.