Skip to content

Documentation

sreemail is a transactional email API built around per-customer isolation.

Start here

  • Quickstart — verify a domain and send your first email.
  • Authentication — API keys and scopes.
  • Errors — the stable error codes worth branching on.
  • Limits — sizes, rates, quotas, and why the attachment cap is what it is.

How sending works

A send is accepted, not performed, at request time. POST /v1/emails validates the request, runs it through ownership, suppression and limit checks, writes a message row, and returns 202 with an id. The message is handed to a queue and delivered by a background consumer.

That indirection is what makes per-tenant pacing, retry on upstream throttling, and scheduled delivery possible without holding your connection open. The delivery outcome reaches you as a webhook.

The isolation model

Every organization maps to an isolated sending tenant with its own suppression list and its own reputation metrics. This is the reason the product exists:

  • A hard bounce recorded for one customer does not suppress that address for any other customer.
  • Bounce and complaint rates are attributable to a single tenant rather than averaged across your whole account.
  • A tenant that crosses its thresholds is paused automatically, before the shared IP pool everyone else sends on is affected.

An organization cannot send until that infrastructure exists. Until then, requests are refused with organization_not_provisioned rather than failing with an opaque upstream error.

Conventions

  • Base URL is https://api.sreemail.com. All endpoints are under /v1.
  • Requests and responses are JSON. Timestamps are ISO 8601 with an offset.
  • Identifiers are prefixed and sortable: msg_use1_01JQ…. The middle segment is the region that owns the record.
  • List endpoints paginate with limit and a before cursor, newest first.

OpenAPI

The full specification is at /openapi.json — OpenAPI 3.1, covering every /v1 endpoint. Request and response schemas are generated from the same definitions the API validates against, and a test fails the build if a route exists that the spec does not describe. Point a client generator at it if you work in a language we do not ship an SDK for.