SMS, WhatsApp and RCS

Sent integration

Ahena works with your Sent account, or one of its sender profiles: it checks that SMS, WhatsApp and RCS are ready to send (10DLC and other registrations included), creates the message templates your app declares and submits them for review, and creates the delivery webhook with its signing secret stored encrypted. Your app sends straight to Sent through the generated ahena.sms code. Ahena never sends a message or reads contacts or message history.

BetaFull Sent docs

What Ahena inspects

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

The account behind the key (organization, standalone or sender profile) and its sender profiles' setup status.
Each SMS market (country and sender type) with its status and Sent's reason, plus WhatsApp and RCS status. Brand and campaign data, tokens and agent contact details are dropped.
Templates: name, status, category, language, channels and variable names (Sent doesn't return the copy).
Webhooks: URL, subscriptions, whether they're on and recent delivery failures; never the signing secret.
Whether your webhook route rejects a request without a valid signature.

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
Create a declared template and submit it for review	CONFIRMATION_REQUIRED	Matched by name; sent with an Idempotency-Key. Approval by Meta or Sent is asynchronous, so Doctor reports it until it's decided.
Submit a DRAFT template for review	CONFIRMATION_REQUIRED	Only the review request; the content isn't touched.
Create the delivery webhook	CONFIRMATION_REQUIRED	Sent returns the signing secret once; Ahena stores it encrypted as `SENT_WEBHOOK_SECRET`.
Add missing webhook subscriptions, or turn the webhook back on	CONFIRMATION_REQUIRED	Subscriptions are only ever widened.

Refused outright:

Sending messages, and reading contacts, conversations or message history.
Editing or deleting existing templates, and deleting or turning off webhooks.
Numbers, SMS markets, WhatsApp, RCS, sender profiles and 10DLC registrations: they're billed or reviewed, so Doctor gives the manual steps.
Webhook URLs that aren't public https or that embed credentials.

Generated code: src/ahena/sms/index.ts (the provider-neutral sms.send({ to, body }) and sms.raw, shared with Twilio; body is sent as Sent's free-form text on SMS), src/ahena/providers/sent.ts, .env.example.sent and, with Next.js, a webhook route that verifies Sent's signature and rejects anything unsigned or stale.

How Ahena verifies

After every write, Ahena reads Sent 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 (templates by name, webhooks by URL) and made only if absent, then read back with full page-by-page listing.

Templates are verified by existence: Sent returns status, variables, category and language but not the copy.

Webhooks are read back in full; the signing secret can't be read after creation and is never returned.

If a request may have reached Sent 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 Sent docs.

Check	What it means
`sent.credentials / sent.sender_profile`	The key works and can act for the declared sender profile; the profile's setup status.
`sent.channel.sms / .whatsapp / .rcs`	Each declared channel is ACTIVE, with Sent's reason and manual steps when it isn't.
`sent.channel.sms.market.<market>`	A 10DLC or other registration that isn't finished yet (WARNING, manual).
`sent.template.<name>`	Approved, waiting for review, draft, rejected or missing.
`sent.webhook / .failures`	A webhook for the endpoint, on, with the subscriptions; recent failed deliveries.
`sent.webhook.endpoint`	One unsigned POST to your route: rejected is good; a 2xx means it doesn't verify signatures.

More on findings, health and continuous checks: Doctor.

Approvals

Sent changes here are classified CONFIRMATION_REQUIRED. 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.

Add an SMS sender, connect WhatsApp or request RCS in the Sent Dashboard, and finish 10DLC registration where Doctor says so.
Wait for template reviews; revise a rejected template in Sent or declare new copy under a new name.
After deploying the webhook route with its secret, send a test event from the webhook's page in Sent.

Credentials and permissions

Name	Secret	Notes
`SENT_API_KEY`	Yes	An API key for Ahena (Sent Dashboard → Development → API Keys). An organization key can act for one of its sender profiles (`sms.senderProfile`).
`SENT_WEBHOOK_SECRET`	Yes	Created with the webhook and stored encrypted. Read it back with `ahena env reveal <environment> SENT_WEBHOOK_SECRET` (always audited).

Least privilege

Sent keys have no scopes and one format for test and production, so Ahena checks only that the key works, and says so.
Give Ahena its own key and your app another, so either can be deleted alone.

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.

SENT_API_KEY=… ahena connect sent -e production

Connect with an API key.

```
ahena doctor -e production
```
Check the profile, channels, registrations, templates and webhook.
```
ahena plan -e production
```
See the template and webhook changes.
```
ahena apply -e production
```
Approve and apply; the webhook signing secret is stored encrypted.

ahena generate sent -e production --framework nextjs

Write the SMS 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 Sent is tested

Sent is tested against a simulated version of its API: x-api-key auth, organization keys acting for profiles, the error envelope and codes, page-by-page listing, Idempotency-Key replay, the read-back after each write and idempotent re-apply.
It hasn't been run against the real Sent API yet.
The generated code is typechecked against the real @sentdm/sentdm SDK, and the webhook route's signature check is run in tests.

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

Limitations

Ahena doesn't buy numbers, add markets, connect WhatsApp, request RCS, create sender profiles or file 10DLC registrations.
A test key in production can't be detected: Sent has one key format.
Existing templates are never edited, and their copy can't be read back; AUTHENTICATION templates, headers, footers and buttons aren't modelled.
Free-form text delivers only inside an open conversation; first messages need an approved template, sent through sms.raw.

Disconnecting

ahena disconnect sent removes the stored key; Sent has no revoke API, so delete Ahena's key in the Sent Dashboard. Profiles, channels, templates and webhooks are untouched.