Boundry documentation

Transactional email
that stays regional.

Boundry is the transactional email API for developers with explicit data residency. Cloudflare handles your account and project directory; every project’s messages, inbound content, logs and key hashes stay in its selected region.

Get started

Set up each Boundry project independently. It gives you a genuinely separate delivery workspace and data boundary.

Create an Australian project Sydney is Boundry’s only live region. The region is permanent.

Verify a sending domain Publish the project’s SPF and DKIM records.

Create a project API key Use it only with this project’s Sydney endpoint.

Send your first message Then add native inbound and webhooks where needed.

Sydney is available now. Production requests go directly to https://api.au.boundry.dev. The local environment uses an SESv2 emulator with the same application surface.

Quickstart

Create an API key in Dashboard → API keys, export it locally, then send through the project’s regional endpoint.

bashTerminal

export BOUNDRY_API_KEY="<your API key>"

Shellsend.sh

curl -X POST https://api.au.boundry.dev/emails \
  -H "Authorization: Bearer $BOUNDRY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <hello@acme.com>",
    "to": ["ava@northwind.com.au"],
    "subject": "Welcome to Acme",
    "html": "<p>It works.</p>"
  }'

API

Keep the endpoint regional. Your configured endpoint is https://api.au.boundry.dev.

Regional projects

Organisations are the central account layer. Projects are regional delivery workspaces. A single organisation can create separate projects for separate environments or jurisdictions.

AcmeOrganisation · central account data

Production AUProject · Sydney data plane

Future regionNot yet available

Project-level data includes domains, API-key hashes, sends, delivery events, inbound messages, webhook deliveries and retention policy. Cloudflare holds the central project directory, but it does not store message content or logs.

TypeScriptNode.js

const response = await fetch("https://api.au.boundry.dev/emails", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.BOUNDRY_API_KEY}` },
});

Your configured endpoint is:

textRegional API endpoint

https://api.au.boundry.dev

Send email

Send a transactional message through your project’s regional endpoint. Requests are authenticated with an API key created inside that project.

textEndpoint

POST /emails

Returns: { "id": "msg_..." }

Use an idempotency key when your application can retry a request. Boundry stores the request and delivery lifecycle in the selected project region.

Add a domain

Domains belong to one project and one region. The dashboard supplies the DNS records to publish, then verifies them automatically.

Choose the domain Enable sending, receiving, or both.

Publish DNS records Add DKIM and SPF for sending; add MX for inbound.

Verify and activate Boundry checks DNS, then enables the selected capability.

Use a dedicated subdomain for inbound—such as replies.acme.com—unless you explicitly intend Boundry to receive all normal company email. Changing the MX record on acme.com can interrupt mail delivered to Google Workspace or Microsoft 365.

Receive email

Native inbound turns a Boundry project into an application email receiver. It is built for replies, intake forms, tickets and message processing—not a human IMAP mailbox.

Inbound API→Regional store→Message event→Project webhook

When a message arrives, Boundry validates the receiving domain, stores the parsed content in the regional data plane, records the inbound event, then delivers a signed webhook. The local dashboard has an inbound simulator; applications use POST /inbound.

jsonWebhook event

{
  "type": "email.received",
  "data": {
    "id": "inb_01J...",
    "from": "buyer@example.com",
    "to": ["support@replies.acme.com"],
    "subject": "Need help"
  }
}

Inbound endpoints:

textEndpoints

GET /emails/receiving
GET /emails/receiving/:id
GET /emails/receiving/:id/attachments

Webhooks

Webhooks are configured inside a project and delivered from that project’s data plane. Every delivery is HMAC-signed and recorded.

email.sent and email.delivered
email.bounced and email.complained
email.received for native inbound email

Keep webhook payloads small. Use the event’s message ID to fetch full content and attachments from the regional API.

Retention

Retention is configured per project, not per organisation. A strict workload can keep only delivery metadata; another project can retain content long enough for debugging and inbound workflows.

Outbound bodyConfigurable

Inbound contentConfigurable

Delivery metadataConfigurable

For zero-persistent-content workflows, Boundry processes the message in the selected region, sends it or delivers the webhook, and retains only the minimal metadata the project has chosen.

Transactional emailthat stays regional.