A reply endpoint must preserve conversation context, sender identity, and human intent while separating provider acceptance from actual delivery or recipient engagement.
Accept the parent message or thread identifier and let the connector derive provider context. For standards-based mail, preserve Message-ID relationships through In-Reply-To and References headers rather than reconstructing a thread from subject text alone.
The authenticated account, configured aliases, and provider policy determine the valid From value. Reject arbitrary sender substitution and show the actual sender and recipients before a user confirms a sensitive reply.
Draft-first workflows are safer for generated text. Store the business decision, approval actor, final content hash, and idempotency key so a retry cannot create a second reply.
A successful API response means the provider accepted or created the message. It does not prove final delivery, an open, or a human reply. Return the provider message ID and later state changes only when supported evidence arrives.
Use the provider's thread or reply operation when available. For standards-based mail, construct the reply with the parent's Message-ID in In-Reply-To and extend the References chain.
No. It proves only the state the provider reports at submission time. Delivery, bounce, open, and reply evidence are separate and not uniformly available from mailbox APIs.
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.