How to Send Emails From Supabase Edge Functions (2026)

Keep provider credentials in Edge Function secrets

Store the email API key with Supabase secrets and read it only inside the function. Never expose it through a browser bundle, public environment variable, or client-side Supabase call. Use a separate provider key and sending domain for local or staging tests.

Choose the right source event

Use Auth hooks for authentication-related messages, database webhooks for durable row changes, and explicit server calls for product actions. Do not infer a high-stakes email from a client event that can be replayed or forged. The source should represent a committed server-side state change.

• ok Use a server-owned event for password, billing, and permission changes.
• ok Validate the intended recipient against the database.
• ok Separate transactional triggers from marketing consent.

Create an idempotency key from the committed event

Combine the event type with a durable record ID or event ID. Store the key before calling the provider and reject reuse inside the relevant window. Edge Functions can be retried, and database webhooks can deliver more than once, so provider success cannot be the only deduplication layer.

Move slow or retryable work behind a queue

A simple message can be sent directly when the function has a strict timeout and the provider responds quickly. Anything involving enrichment, multiple recipients, attachments, or retry policy should create a durable job and return. The job worker owns backoff and final failure handling.

Test with production-shaped events and non-production recipients

Capture representative Auth and database payloads, replay them in a local function, and assert the recipient, template, variables, and idempotency key. Route staging sends to a controlled inbox and verify provider logs before enabling the trigger for real users.