Tenant Isolation

useSend is multi-tenant. In this deployment, one AWS install of useSend serves every EverJust product, and a Team is the tenant boundary. Each product gets its own Team; a Team owns its sending domains, API keys, templates, contacts, and email logs, and nothing crosses that line under normal operation.

The model

Every resource in useSend belongs to exactly one Team:

• Domains — verified sending domains (e.g. send.everjust.app) are registered under a Team.
• API keys — the us_ prefixed keys are minted inside a Team. An API key resolves to exactly one Team; there is no cross-Team key.
• Templates, contacts, contact books — created and read within a Team.
• Emails & logs — send records, delivery events, and suppression entries are Team-scoped.

When a request arrives with Authorization: Bearer us_xxx, useSend maps that key to its Team and constrains the operation to that Team's resources. A key for the EverJust Team can only send from EverJust's verified domains and can only read EverJust's logs.

Isolation is application-layer

This is the important caveat. Tenant isolation in useSend is enforced in application code — every query is expected to filter by the caller's Team id. There is no database row-level security: the isolation guarantee is only as strong as the correctness of those query filters.

useSend (formerly Unsend) is beta software with a history of patched team-scoping bugs — cases where an endpoint failed to constrain a query by Team, exposing or acting on another tenant's data. That history is not a reason to avoid useSend; it is a reason to treat cross-tenant isolation as something you verify, not something you assume, especially before you co-host unrelated commercial products that must not see each other's data.

Before co-hosting: run isolation tests

Provision two Teams — call them Team A and Team B — each with its own domain, API key, a template, and a contact. Then, using only Team A's key, confirm that every attempt to touch Team B's resources fails (401/403/404, never success or another tenant's data).

A minimal IDOR probe — Team A's key against a Team B email id — should look like this and must not return 200:

# Using Team A's key against a known Team B email id → expect 403/404, never 200
curl -i https://mail.everjust.app/api/v1/emails/<team_b_email_id> \
  -H "Authorization: Bearer us_teamA_key"

Reputation isolation

Query-level isolation keeps data apart. It does not keep sender reputation apart — that is a property of AWS SES, not useSend. If two products share the same SES sending identity and reputation surface, one product's bounce and complaint rates can drag down the other's inbox placement.

Give each high-value tenant its own reputation surface:

• Dedicated SES configuration set per Team. A configuration set is where SES tracks reputation metrics and event publishing. Isolating it per tenant means bounces and complaints are attributed and (optionally) throttled per product rather than pooled.
• Dedicated IP pool (optional, for volume senders). For a product with meaningful volume and its own reputation to protect, assign a dedicated IP (pool) so its sending reputation is fully independent of the shared warm-up pool. Low-volume tenants are usually better on the shared pool — a dedicated IP needs consistent volume to stay warm.

Configuration sets and IP pools are provisioned on the AWS/SES side (Terraform infra lives in the repo below), then bound to the tenant's domain. Plan this at Team-creation time for any product whose deliverability you cannot afford to have coupled to another's.

Repo

Terraform for the SES configuration sets and IP pools, plus the useSend deployment and these docs, lives in the private repo github.com/EVERJUST-DEV/usesend-email. Record the pinned useSend version there alongside the last isolation-test run.