Add email to Astro without leaking a key into the static build. The server endpoint is the boundary.
Use an Astro server endpoint for transactional sends and product events, then trace the accepted message through the same lifecycle system.
✓Needs an SSR adapter. Keys never belong in a static build.
One request, complete trace
Request
POST /api/v1/emails
Authorization: Bearer aem_…
Idempotency-Key: welcome-8f21
{ "to": "[email protected]", "template": "welcome" }
202 Accepted
{ "id": "msg_7ca31", "status": "queued" }
[ 01 / 03 ]Integration shape
Make Astro's deployment mode explicit before you send.
Use API routes and server islands
API routes need an on-demand SSR adapter. A fully static deployment has no trusted runtime for the key.
Publish product events
Publish signup or trial events from the endpoint that receives trusted application state, not from an island in the browser.
Verify the webhook
An export const POST endpoint reading the raw Request body.
[ 02 / 03 ]Server quickstart
Queue an email from an Astro API route.
The endpoint keeps the credential private and returns an accepted message ID your application can trace.
Run this endpoint in a server-rendered Astro deployment, not a static browser bundle.
export const POST: APIRoute = async ({ request }) => {
const input = await request.json();
return fetch(EMAIL_URL, { method: "POST",
headers: authHeaders(`welcome-${input.userId}`),
body: JSON.stringify({ to: input.email, template: "welcome" }) });
};Accepted response
{ "id": "msg_7ca31", "status": "queued" }Questions people ask us
Give your Astro app a real email backend.
Add one server endpoint, queue a message, and keep the credential out of the client build.