Setup

Add a sending domain

POST
/api/v1/domains

Registers the domain with the project's provider and returns the DNS records to publish, plus a recommended DMARC record (dmarc.recommended_record) — Gmail/Yahoo bulk-sender rules require DMARC on the From domain, but the provider does not, so it's advisory. A human still has to add them at the DNS host; then call the verify endpoint. Sends from an unverified domain are refused. Requires an admin-scope key.

Authorization

bearerAuth admin
headerAuthorizationBearer <token>

An API key from the dashboard under Settings → API keys, sent as Authorization: Bearer aem_….

Authorization has two independent axes.

The scope is ranked — a key satisfies any requirement at or below its own tier:

  • read — see messages, contacts and metrics. Changes nothing, and cannot send.
  • write — everything read does, plus managing templates, contacts, automations, segments and suppressions. This is what editing a template needs.
  • admin — everything write does, plus sending configuration: domains, senders, webhook registration, kill switch, daily cap, brand.

There is no approve scope. It was a rung once; it is not one now, and a key requested with it is rejected.

The approval grant (can_approve) is a separate boolean, not a rung. Delivering mail to a real inbox needs write and the grant. Keeping them on separate axes is what makes the review gate a control rather than a convention: a key that may propose is not automatically a key that may approve its own proposal.

Give your application the lowest tier that works. Most need write and the grant — the dashboard mints that combination as Send + manage; Manage only is the same rung with the grant withheld.

Scope: admin

Header Parameters

Idempotency-Key?string

Makes a retry safe (1–256 chars, kept 24 hours). The same key with the same body replays the first success with Idempotency-Replay: true; the same key with a different body, or while the first request is still running, is 409 conflict. A failed request releases its key. Use a value tied to the thing you are creating, e.g. onboarding/user_42.

Length1 <= length <= 256

Request Body

application/json
  1. body
domain*string

Bare domain to send from.

Match^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$
Length3 <= length <= 253

Response Body

Domain registered. Publish dns_records, then verify.

application/json
  1. response
id?string
domain?string
status?string
dns_records?array<>
dmarc?

Advisory DMARC state from our own DNS check. Never blocks verification; Gmail/Yahoo bulk-sender rules require a DMARC record on the From domain.

tracking?|

Domain-level open/click tracking (Resend). Null for SendGrid — tracking is applied per send there. The tracking CNAME rides in dns_records (record: 'Tracking'); click events won't fire until it resolves.

Example Request
curl -X POST 'https://sendandretain.com/api/v1/domains' \  -H 'Content-Type: application/json' \  -d '{  "domain": "mail.acme.com"}'
Example Response
{  "id": "string",  "domain": "mail.acme.com",  "status": "pending",  "dns_records": [    {      "type": "TXT",      "name": "string",      "value": "string",      "priority": 0    }  ],  "dmarc": {    "status": "missing",    "record": "string",    "recommendedRecord": {      "type": "TXT",      "name": "_dmarc.mail.acme.com",      "value": "v=DMARC1; p=none;",      "note": "string"    }  },  "tracking": {    "open": true,    "click": true,    "subdomain": "tk"  }}