Email Editing and Delivery: Define the Handoff

A user clicks Send after finishing an email. Behind that single action, your application may save a draft, render HTML, resolve personal data, submit a job and wait for delivery feedback.

Email editing and delivery meet at that boundary. Giving every step a clear owner makes errors understandable and helps prevent the wrong version from reaching recipients.

Separate the document from the outgoing message

The editable document contains structure: headings, paragraphs, image references and design settings. An export contains the rendered HTML and a text alternative. A send job adds a recipient, sender details and operational state.

These artifacts have different lifetimes. You might reopen a document for next month’s announcement while keeping an earlier send record unchanged. Re-exporting the latest draft should not rewrite the record of what was previously sent.

Weavour handles email creation, hosts templates and images and exports HTML. Your application handles sending. The documented SDK method exportHTML() returns { html, text, document }; it does not select an audience or submit a delivery job. The React Email rendering documentation likewise treats markup generation as its own operation.

Write down a host-owned handoff contract

Consider an announcement called “New reporting dashboard.” Your backend might accept a document ID, saved revision, subject, HTML, plain text and audience selection. This is an illustrative application contract, not a Weavour endpoint or SDK payload.

The important part is the meaning of each field. Does the subject come from the current draft? Is the HTML a snapshot of revision 18? Must every personalization token be resolved before submission, or will the sending system resolve it for each recipient?

Record these decisions explicitly. If a user edits the draft after approval, your product should either require another approval or preserve the already-approved snapshot. A hidden mixture of old approval and new content is difficult for anyone to reason about.

Keep recipient decisions on the backend

The host application knows which authenticated user requested the send, which customer owns the audience and which recipients are eligible. Validate those relationships on the server rather than trusting browser-supplied IDs or addresses.

Keep provider credentials there as well. The editor does not need access to a sending secret to produce an email. Embedded userId and organizationId values in Weavour are declared namespaces, not verified end-user identities; administrative approval must come from your application’s authenticated context.

Apply your own preference and suppression policies at the point where the audience becomes a send job. A preview prepared earlier may no longer reflect the current recipient list. Define the policy for those changes instead of assuming the editor can enforce it.

Give each failure its own recovery path

If export fails, keep the draft visible and explain which preparation step needs attention. If your backend rejects an audience, let the user correct the selection without losing the email. If a provider request times out, determine whether the job was accepted before offering an unrestricted retry.

Use a stable application-side job identifier so repeated clicks do not create separate campaigns accidentally. Store the content revision with that job and track provider responses separately from later delivery events.

Provider acceptance is not the same as inbox placement. Amazon SES’s deliverability explanation describes why sending operations also involve reputation and feedback. Use status labels that match the evidence you actually have.

Test one message across the whole boundary

For the reporting announcement, run a small end-to-end exercise:

• Save a revision and export exactly that content.
• Preview it with both complete and missing recipient data.
• Submit it to one internal recipient through your backend.
• Retry the same request and check your duplicate policy.
• Inspect the received email, links and text alternative.
• Find its document revision from the send record.

The handoff is reliable when each component can explain what it accepted and produced. Sketch those responsibilities before wiring the Send button. Then use Weavour as the creation layer inside the delivery workflow your application already owns.