Resend integration

Ahena works with your Resend account: it adds and verifies your sending domain, works out the DNS records it needs, sets up webhooks and checks deliverability. Your app sends through the generated email code straight to Resend. Ahena isn't in the path.

BetaFull Resend docs

What Ahena inspects

Read-only: inspecting and Doctor never change anything at Resend.

The key, and whether it's full-access or sending-only.
Your sending domain's status and its SPF and DKIM records.
DMARC, through a public DNS-over-HTTPS lookup (no credentials).
Webhooks for your configured endpoint, and whether your route rejects an unsigned request.

What Ahena configures

You declare what you want in ahena.config.ts; ahena plan shows each change with its classification before anything is applied.

Change	Classification	Notes
Add the sending domain	CONFIRMATION_REQUIRED	—
Ask Resend to re-check DNS	SAFE	Changes nothing else.
Create the webhook	CONFIRMATION_REQUIRED	Resend returns the signing secret once; Ahena stores it encrypted as `RESEND_WEBHOOK_SECRET` and never shows it in plans, output or logs.

Generated code: src/ahena/email/index.ts (email.send, email.raw), src/ahena/providers/resend.ts, .env.example.resend and, with Next.js, a webhook route that verifies the signature and rejects unsigned or tampered requests.

How Ahena verifies

After every write, Ahena reads Resend back. Each change ends in one of these states, and the plan's outcome says why:

VERIFIED: Ahena read the provider back and saw the desired state. The CLI shows ✓ only for VERIFIED.
APPLIED_UNVERIFIED: The provider accepted the change, but the re-read doesn't show it yet (after bounded polling), or the re-read failed.

Creates are read, matched and made only if absent, then read back, with full pagination. Domain verification honestly stays APPLIED_UNVERIFIED while DNS propagates.

DNS records go through your DNS provider as a reviewed diff: ahena configure cloudflare --records-from resend shows them as a Cloudflare plan, under Cloudflare's own safety rules.

If a request may have reached Resend but the answer was lost, Ahena re-reads before deciding: done, safe to retry, or “check before retrying”.

What Doctor diagnoses

Key checks from ahena doctor. Each finding says why it matters, where, the impact and whether Ahena can fix it. The full list is in the Resend docs.

Check	What it means
`resend.key`	The key works; a sending-only key is explained.
`resend.domain`	Domain verified, pending, failed or missing.
`resend.domain.spf / .dkim`	Each record's status, with the exact record to add (FAIL in production).
`resend.domain.dmarc`	DMARC enforced, monitoring only (`p=none`), or missing.
`resend.webhook`	A webhook exists for the configured endpoint, enabled, with the events.
`resend.webhook.endpoint`	One unsigned POST to your route: rejected is good; a 2xx means signatures aren't verified.

More on findings, health and continuous checks: Doctor.

Approvals

Resend changes here are classified CONFIRMATION_REQUIRED and SAFE. Every change is planned and shown as a diff first. Ahena itself enforces who can approve it:

SAFE changes are applied without asking.
In production, every other change needs approval in the Ahena dashboard, signed in, by an admin.
In other environments, CONFIRMATION_REQUIRED changes are approved in the CLI; BILLABLE and DESTRUCTIVE changes always need the dashboard.
MANUAL steps are never applied by Ahena.

--yes and --allow-billable don't replace a dashboard approval. See approvals for how it works and why the browser.

Manual steps

These are MANUAL: Ahena never does them. It lists them with the exact steps when they apply.

DNS not on a connected provider: add the records Doctor lists at your DNS host, then run ahena configure resend.
Sending-only key connected: ahena disconnect resend, then reconnect with a full-access key.

Credentials and permissions

Name	Secret	Notes
`RESEND_API_KEY`	Yes	A full-access key (`re_…`) for Ahena: sending-only keys can't list or create domains and webhooks.
`RESEND_WEBHOOK_SECRET`	Yes	Created by Ahena with the webhook. Read it back with `ahena env reveal <environment> RESEND_WEBHOOK_SECRET` (needs the reveal permission, always audited).

Least privilege

Ahena's key needs full access, for domains, verification and webhooks.
Give your app a separate sending-only key restricted to your domain, so a leaked app key can only send from that domain.

Each credential Ahena stores gets its own key and is envelope-encrypted, bound to the environment. See security.

Workflow example

Connect, check, plan, then apply. Placeholders (…) stand for your own values.

RESEND_API_KEY=re_… ahena connect resend -e production

Connect with a full-access key.

```
ahena doctor -e production
```
Check the domain, SPF, DKIM, DMARC and the webhook.
```
ahena configure cloudflare -e production --records-from resend --with-dmarc
```
If Cloudflare holds your zone: review the records Resend needs as a Cloudflare diff.
```
ahena plan -e production
```
See the domain and webhook changes.
```
ahena apply -e production
```
Approve and apply; Resend is asked to verify the domain.

ahena generate resend -e production --framework nextjs

Write the email adapter and the webhook route.

Verification status

Beta

Available in beta. Every capability is validated by Ahena's automated provider contract and conformance tests; verification against the real service is next.

How Resend is tested

Resend is tested against a simulated version of its API and contract fixtures, including pagination, the read-back after each write and unknown-outcome recovery.
It hasn't been run against the real Resend API yet. Real pagination parameters, the duplicate-domain response and verification with real DNS are still to be settled.
The generated email code is run in Ahena's tests with Ahena stopped; the generated webhook route is typechecked but not executed.
Resend has no test or live distinction, so environment safety relies on separate domains per environment.

The providers overview explains Ahena's testing methodology and what has been verified for every provider.

Limitations

Ahena doesn't delete domains, webhooks or API keys.
DMARC is only suggested; with --with-dmarc Ahena adds a p=none record through the DNS provider.
Broadcasts, audiences and templates are out of scope.

Disconnecting

ahena disconnect resend removes the stored key and links you to Resend's API keys page to revoke it; domains, webhooks and history are untouched.