A small Send Email example you can adapt quickly
This example keeps outbound email explicit: one binding, one recipient rule, one worker path that sends one message.
It is enough to teach the binding honestly without dragging inbound processing or full provider workflows into the very first page.
- Config focus
- Explicit destination rules
- Runtime shape
- Call from a worker route
- Best use
- Transactional or support notifications
Start by wiring the binding clearly in config
Minimal Send Email config
import { defineConfig } from 'devflare/config'
export default defineConfig({
name: 'send-email-example',
files: {
fetch: 'src/fetch.ts'
},
bindings: {
sendEmail: {
SUPPORT_EMAIL: {
destinationAddress: 'support@example.com'
}
}
}
})
Then use it in one honest runtime path
- Keep the first outbound example narrow so the binding contract stays obvious.
- If you also handle inbound email elsewhere in the app, document that on the email-event pages rather than merging the two stories here.
Send one email from the worker
import { env } from 'devflare'
export async function fetch(): Promise<Response> {
await env.SUPPORT_EMAIL.send({
from: 'noreply@example.com',
to: 'support@example.com',
subject: 'New support request',
text: 'A customer asked for help.'
})
return new Response('sent')
}
Keep the first version boring on purpose
One message is enough to teach the binding
You do not need a full notification system on the first page. One send call already proves the important contract.
Previous
Testing Send Email
Send Email is stronger locally than many platform-service bindings because outbound email can be exercised in the default harness, while inbound email has its own related helper surface.