Go-live checklist

Run through this before your first customer’s real email goes out. Each item is something that’s cheap to get right now and painful to fix with live traffic. There are no test keys or test workspaces: the key, workspaces and endpoint you’ve built with are the ones you go live with, so this is mostly about making sure they’re set up the way you mean them.

Sending domain

All seven records on the console’s domain screen show verified.
Each workspace you’ll send from shows sending.state ready:

curl https://api.sendtruss.com/v1/workspaces/ref:cust_4821 \
  -H "Authorization: Bearer $SENDTRUSS_API_KEY"

Someone on your team gets alerted by a sending_domain.changed webhook with sendable false, so a broken DNS edit doesn’t silently stop every customer’s email.

See Sending domain and DNS.

API keys

Your key lives in your backend’s secret store, never in client code, a browser or a mobile app. It can do everything for every workspace.
Each environment of yours that calls us has its own key, so you can revoke one without touching the others.
You know how to rotate: create a key on the console, deploy it, revoke the old one.

Event types, templates and attributes

Your deploy registers every event type you emit, and every attribute definition you use exists. Registering an unchanged schema does nothing, so this is safe on every deploy.
Every event type you expect to send email has a template, and you’ve previewed it with a realistic payload, in every locale you send.
Display names use {{ workspace_name }}, so guests see your customer’s name, not yours.
No template’s preview lists a tag in fallen_back that you expected to have a value.

Contacts

Each customer’s existing contacts are backfilled with the batch upsert before their first campaign, and every refused result was looked at.
You send marketing only for people who agreed (or said no), with the time they did. Everyone else stays pending.
Your live sync calls the upsert on each change, by your own reference.

See Sync your contacts.

Emits

Every idempotency key comes from your own record (the booking’s id and what happened to it), never a random value per attempt.
Your code retries network errors, 5xx and 429 with the same key, waits for Retry-After on a 429, and doesn’t retry a 422 or 409 unchanged.
You’ve emitted to delivered@, bounce@ and complaint@simulator.sendtruss.com and seen each outcome reach your handler, marked simulated.
You’ve emitted to your own inbox from a real workspace, and the email arrived from the workspace’s subdomain with its display name.

See Send transactional email for your events.

Webhooks

Your endpoint is registered for every type you handle, and its signing secret is in your secret store.
Your handler verifies with the function from the webhooks reference, against the raw body.
It answers 2xx within 10 seconds and does its work afterwards.
It dedupes on the webhook’s id, and answers 2xx to types and fields it doesn’t know.
Someone knows to look at the webhook list when an email seems to be missing.

See Handle and verify webhooks.

Errors

Your code branches on each error’s code, never its message, which may change.
Your logs keep the request_id of every failed call (it’s also in each response’s Request-Id header). Quote it when you ask us about a request.

Your customers’ lifecycle

When a customer stops paying, your platform suspends their workspace, and resumes it when they’re back.
When a customer leaves for good, your platform deletes their workspace.
When a person asks a customer to forget them, your privacy flow erases them. See Privacy and erasure.