The Tricknowtech Email API Won't Send Your Newsletter — On Purpose

Most businesses don't need an email marketing platform. They need something much narrower: a password reset that actually arrives, a receipt that matches the order, a shipping notification that doesn't get eaten by a spam filter. That's a different problem than newsletters, and it needs different infrastructure. The Tricknowtech Email API is built for exactly that narrower problem — and, more unusually, it enforces the boundary itself rather than trusting you to stay inside it.

What "transactional-only" actually means

The Email API runs on AWS SES infrastructure and is scoped to transactional sends only: order confirmations, receipts and invoices, password resets, shipping notifications, appointment reminders, and account or security alerts. That's the full list of what it's for.

It does not support marketing or bulk email — no newsletters, no promotional blasts, no drip campaigns. That's not a usage guideline you're expected to self-police. It's a real, enforced restriction, and the next section is about how it's enforced.

Why an LLM reads every email before it sends

AWS SES grants production sending access on the condition that the traffic passing through stays genuinely transactional. Rather than leave that as a policy line customers are trusted to follow on their own, Tricknowtech built the check directly into the send path: every email, whether it comes from a saved template or from freeform content passed in on the call, is checked by an LLM before it sends. The question it's asking is specific: is this actually a transactional message, or is it marketing content wearing a receipt's clothing?

Templates and freeform sends are checked on different schedules, because they carry different risk. A saved template is reviewed once, when you create or edit it, and approved automatically — usually within seconds — so that day-to-day sends using an approved template aren't held up waiting on a model call. Freeform content, where the body can be anything on any given call, is checked live, every time, because there's no prior approval to lean on.

Setting up your sending domain

Sending under your own domain rather than a shared one is table stakes for transactional mail — recipients and mail providers both trust it more. Verifying a custom sending domain is built into the account: if the domain is already hosted with Tricknowtech, DKIM is configured automatically. If it's hosted elsewhere, you add a small set of CNAME records at whatever DNS provider you're already using, and verification picks up from there.

Knowing what happened to every send

Sending the email is the easy part. Knowing whether it actually arrived is where most homegrown email setups fall down — someone has to handle bounces, track complaints, and make sure a hard-bounced address doesn't get emailed again next week. The Email API handles this automatically: bounce and complaint events feed a suppression list maintained on your behalf, so a dead address or a spam complaint stops future sends without you writing that logic yourself.

For anything you want to react to in your own systems — marking an order as "confirmation email delivered," flagging an account after a bounce — delivery, bounce, and complaint events can be pushed to a webhook URL you configure. If you set a webhook secret, every payload is HMAC-signed so you can verify it actually came from Tricknowtech before acting on it.

And for the moments you just need to look something up — did that receipt go out, why did that one send get rejected — real-time API logs show every send with its delivery status and, when something failed, the exact rejection reason. Not a generic "failed," the actual cause.

Two ways to send: from your code, or by asking an assistant

For a normal backend integration, there's a published, zero-dependency TypeScript SDK — @tricknowtech/email — for calling the API directly from your own server. It's a thin wrapper, no extra runtime baggage, built to match the real API contract rather than generated from a spec after the fact.

The less obvious path is the Tricknowtech MCP server. The same send_email and list_email_templates functionality the SDK exposes is also available there, which means an AI assistant can send a transactional email or check your verified sending domains on request — no developer sitting down to write an API integration first.

That matters most for the accounts that don't have, and don't need, a dedicated backend developer for this one task — a support workflow that occasionally needs to fire off a manual notification, or a small operations team scripting something together with an AI assistant rather than a full integration. The transactional-only restriction and the LLM check apply the same way regardless of which path sent the email — template, freeform call, SDK, or an assistant acting through MCP.