Under the hood Bindings

How Devflare wires Send Email from config to runtime

Send Email compiles into Wrangler output, normalizes message input at runtime, and supports local address restrictions instead of treating email as an unbounded free-for-all.

That runtime normalization is worth calling out because it lets worker code send higher-level message shapes while Devflare translates them into the lower-level form the email path needs.

Normalization: The schema normalizes address restrictions and runtime message helpers normalize composed email input
Compile target: Wrangler
Preview note: Address rules compile as authored; there is no separate preview resource lifecycle for email destinations

Devflare normalizes the authored shape before it does anything louder

The schema work here is less about ids and more about safety rules: which addresses are permitted and which combinations are invalid.

At runtime, Devflare can normalize higher-level email message shapes into raw MIME-backed delivery when the outbound path needs it.

Send Email from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'email-worker',

bindings: {

sendEmail: {

TRANSACTIONAL_EMAIL: {

allowedDestinationAddresses: ['ops@example.com'],

allowedSenderAddresses: ['noreply@example.com']

SUPPORT_EMAIL: {

destinationAddress: 'support@example.com'

}

})

Local runtime support depends on what Devflare can model directly

Local send-email bindings can be created and enforced in the default runtime/test context.
Address restrictions are part of the local contract, which keeps the binding honest during development.
Inbound email helper APIs exist too, but they serve the inbound event story rather than replacing outbound bindings.

Compile, preview, and cleanup behavior

Compile turns the authored send-email rules into Wrangler-facing entries.
The binding rules are emitted as-is; there is no preview resource provisioning story for destination addresses or sender allow-lists.
The runtime normalization step is the subtle part worth documenting because it shapes how friendly outbound code can look.

Safety rules are part of the binding

The point of the schema is not only to make email possible. It is also to keep where the worker may send email visible and reviewable.

Send Email

Send Email is a real binding surface in Devflare, and it is worth documenting separately from inbound handlers so the two flows do not get blurred together.

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.