Sign people in and talk to them without keeping three copies of the same person at three vendors — and without writing the webhooks that keep those copies agreeing.
No card to get keys. Set a spending cap before you send, and nothing can run past it.
Take one of them or all three. They read and write the same contact, through the same API, rather than three services you keep in step yourself.
The contact they shareAn identity provider knows their password. An email provider knows their address. A carrier knows their number. None of the three knows they are the same human, so you are the one who has to.
A sync job you wrote keeps two records in step. When it lags nothing raises an error — the second record simply stops being true, and you find out when somebody is greeted by the wrong name.
An unsubscribe is a fact about a person that arrives at exactly one vendor. Copying it to the other is your job, and being wrong about it is a compliance problem rather than a bug.
Email and SMS stay separate decisions — a bounce or a STOP arrives for an address, not for a person. What is shared is the contact they hang off and the single page where somebody changes both.
Each vendor meters its own unit on its own schedule. One of them has stopped sending and the other two do not know, because none of them has heard of the other two.
Checked before anything is queued, on every send path and inside the automation engine — so the limit is a refusal rather than a line item you find afterwards.
The difference is not that three products arrive on one invoice. It is that they read and write the same customer state, which is the half a bundle cannot give you.
An identity provider, an email vendor and a carrier each hold a slice of the same person — and a different slice each. The gaps are the code you write.
Both addresses, consent per channel, and the history — on one row that every product reads and writes.
Checked, not asserted —db/src/schema/audience.tscore/src/ops/audience-consent.tscore/src/ops/audience-preferences.tscore/src/audience/policy.tscore/src/billing/usage.ts
Suppression, consent, quiet hours and your spending cap — checked before anything is queued. Your broadcasts, your text messages, and the sign-in codes Lath posts on your behalf all take this route.
Both channels, one page, one contact. Security alerts are transactional — an unsubscribe does not reach them.
Email and SMS stay separate decisions — a bounce or a STOP arrives for an address, not for a person. What is shared is the contact they hang off and the single page where somebody changes both.
Identity, both addresses, what they agreed to on each channel, and what you have sent them — on the same contact, not assembled from three consoles.
Email and SMS consent stay separate decisions — a bounce or a STOP arrives for an address, not for a person. What is shared is the contact they hang off.
One person, from a Google button to a text message they asked for. Every operation named here is real — the test opens the registry and checks.
auth.oauth.completeaudience.contact.createemail.sendauth.identity.verifyThe phone lands on the row that already holds the email.
audience.consent.grantaudience.segment.createNot 'an AI writes some integration code'. Every operation is a tool carrying its input and output schema, so an agent can list what exists, read what each one takes, and call it.
Add authentication to my Next.js app. Let people sign in with email or Google. When someone signs up, send them a welcome email. During onboarding, collect a phone number and verify it by SMS.
auth.settings.setauth.oauth.app.setemail.template.setemail.template.publishdevelopers.webhook.createdevelopers.key.createNot code it drafted for you to debug — configuration it made, by reading each operation's schema and calling it.
Take one of them or all three. What they share is there when you want a second channel and costs you nothing while you do not.
Get them in — by emailed code, magic link, password, passkey, or Google, Microsoft and GitHub.
Sign-in codes, magic links, passkeys, passwords, two-step, social sign-in, organizations, sessions.
Say something to one person or to a segment, from a template that knows their language.
Transactional send, templates with translations, broadcasts, automations, inbound, delivery feedback.
Reach the phone, with the consent and quiet-hours rules the channel actually requires.
Send, templates, quiet hours, STOP, HELP and START keywords, numbers, carrier registration.
One row, read and written by all three — not a fourth product you also have to buy.
The same call — same operation, same arguments, same reply — written six ways. Only the syntax changes, so what you learn on one of them you keep on all six.
email.sendSend avery@example.com the welcome email, with their first name in it.
{
"messageId": "01J9F2...",
"status": "queued",
"to": "avery@example.com",
"template": "welcome",
"templateVersion": 3
}Copy any of these and run it. It creates the account, sets a spending cap, and sends — no key needed to begin, because creating an account is the one operation that does not take one.
# 1. Create an account. This is the only operation that needs no key.KEY=$(curl -s -X POST https://platform.trylath.com/account/signup \ -H "Content-Type: application/json" \ -d '{"email":"you@example.com","country":"US"}' | jq -r .result.live.key)# 2. Cap the month before anything can send.curl -s -X POST https://platform.trylath.com/billing/cap/set \ -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \ -d '{"monthlyCapCents":500}'# 3. Send.curl -s -X POST https://platform.trylath.com/sms/send \ -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \ -d '{ "to": "+14155550100", "body": "Spring sale starts today.", "topic": "promotions" }'Response
{ "activityId": "act_7Qw1e8", "result": { "messageId": "sms_2pK4mA", "status": "suppressed", "to": "+14155550100", "segments": 1, "encoding": "gsm-7", "template": null, "templateVersion": null, "templateLocale": null, "sendAfter": null, "blocked": { "reason": "No carrier registration has been filed for this project yet.", "fix": "Check sms.registration.get for where it has got to. The message is stored and will send once the channel opens; nothing is lost." } }}This is enforced rather than intended: parity.test.ts derives the operations and fails the build if any one of them is missing a REST route, an MCP tool, a CLI command, an SDK method or a dashboard screen — and fails just as hard if a surface carries one the registry does not.
Read the APIEach of these names the file that enforces it, because a guarantee you can go and read is a different kind of claim from one you are asked to take.
parity.test.ts
A test derives the operation list and fails the build if one is missing a REST route, an MCP tool, a CLI command, an SDK method or a dashboard screen — and fails just as hard if a surface has one the registry does not.
runtime.ts
Declared per operation rather than assumed, and the stored response is encrypted at rest.
t=1757…v1=9f2c…sign.ts
Compared in constant time, with a five-minute tolerance, and the endpoint's secret is rotatable without dropping a delivery.
deliver.ts
Every attempt keeps its own row — status, error and duration — so a dead delivery can be read before it is replayed, one at a time or in bulk.
402 spending_cap_reachedusage.ts
Applied on all four send paths and inside the automation engine, under a per-project lock so two racing sends cannot both slip past it.
154 test files —generated/test/parity.test.tscore/src/runtime.tscore/src/webhooks/sign.tsworker/src/deliver.tscore/src/billing/usage.tscore/src/ops/audience-optin.tscore/src/ops/activity.tsgenerated/src/emit-sdk.tscore/src/messaging/delivery.tscore/src/auth/limits.ts
The suite runs against a real PostgreSQL and a real browser on every push. Nothing is mocked to make it faster.
Attach it to the agent you have open, install a typed client, or POST to it from anything that speaks HTTP. Every name here is a package in this repository.
Claude CodeMCP
CodexMCP
CursorMCP
Any MCP clientPOST /mcp
TypeScript@trylath/sdk
React@trylath/react{
"mcpServers": {
"lath": {
"url": "https://platform.trylath.com/mcp",
"headers": { "Authorization": "Bearer lath_live_..." }
}
}
}Built on things you can check.
Every name here is a dependency this repository actually ships.
TypeScript
Next.jsReact
Tailwind CSS
Radix UI
Hono
Zod
PostgreSQLModel Context Protocol
Fly.io
VitestEarly access pricing
Usage-based, with a hard cap you choose. No plan tiers to size yourself against, and no per-seat charge for being reachable on more than one channel.
per email sent
Transactional and broadcast are counted the same way. A send that is suppressed before it leaves is not billed.
per segment
Segments, not messages — a body outside the GSM alphabet costs more than twice as much per character, and the reply says how many were counted.
per monthly active user
Counted once per person over the month — not again because you also emailed them and texted them.
Per-unit rates are published before general availability. The billing engine is built never to guess a price, so neither does this page — and nothing is charged before the numbers are here.
Frequently asked questions
Including the two whose honest answer is still “not yet”. Those are read from the same place as the status section below, so they cannot say different things.
Create an account without a card, set a cap, and send something in the next ten minutes — by hand, from your terminal, or by asking your agent to do it.