Frontend JavaScript should submit a validated intent to your backend; provider tokens, mailbox credentials, authorization decisions, and final sends belong on a trusted server.
Expose a product endpoint authenticated as the current user. The backend verifies workspace membership, connected-account ownership, sender permission, and policy before creating a send command.
Submit connected account ID, recipients, subject, body alternatives, attachment references, reply context, and a client-generated idempotency key. Upload large binaries separately and reference secured attachment IDs.
Persist the request, enqueue provider execution, and return a command or message ID. The browser can receive a signed webhook-derived update or poll that resource until it reaches a documented terminal state.
Disable duplicate submission while the same idempotency key is active, show provider validation errors beside the relevant field, and retain the unsent draft when authentication or quota issues require user action.
Some OAuth flows technically support browser clients, but a multi-tenant SaaS should not expose long-lived mailbox credentials or trust the browser for workspace authorization and send policy. Route sends through the backend.
Users double-click, networks retry, and pages reload. The key lets the server return the original command instead of creating another message.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.