Move Resend receiving to Bird Agent Mailboxes

Move an application-owned email conversation to a Bird mailbox. Resend already supports receiving and threaded replies; this migration changes how your application addresses and processes those conversations.

Resend's incoming event distinguishes the API resource email_id from the RFC email message_id. Its reply guide uses the latter in In-Reply-To, with References for repeated replies. Keep those values separate during migration. See Resend reply handling.

The receiving and attachment capabilities are documented in Resend receiving. If the application only needs to parse incoming mail, consider Bird inbound email before introducing a mailbox.

Record the provider, incoming resource ID and application case ID for historical messages. For new Bird mail, add the mailbox and thread IDs. Do not infer that two conversations are the same because they share a subject.

Keep an old case's archive reference when a customer resumes it after the switch. If the application explicitly associates a new Bird thread with that case, record that decision in the case store; do not rewrite provider IDs or assume the old thread was imported.

Start with the complete Node.js support inbox or Python support inbox. Each creates a mailbox, receives a message, records an application-owned support case and acknowledges it in the original thread. A later message updates that case; a repeated message does not send another acknowledgement.

The examples keep a small local checkpoint for development. Put the same case, incoming-message and outgoing-operation identities in your application's durable store before running multiple workers. Keep the business action separate from the email: acknowledging a refund request does not issue a refund.

Then add the signed event receiver and attachment workflow. Store the received-message ID with the case before acknowledging the event. Retrieve attachment metadata and bytes through the documented operations; keep any retained files under your application's access and retention rules.

Test unrelated messages with the same subject, a reply, a forwarded message and a second customer response. Inspect the resulting conversation in the controlled recipient's mailbox as well as the returned API records.

Repeat an incoming event and confirm it reuses the existing work item. A lost send response needs reconciliation before another reply: Bird's completed-response retention is three hours, and a send can take effect before a response is retained. See idempotency and recovery. Keep a business outcome such as a completed refund separate from the acknowledgement email.

Switch a controlled address or cohort after the receiving and reply tests pass. Reconcile existing Resend jobs before disabling their consumer. If outbound notifications remain on Resend, leave those sends separate or follow the Email API migration.

On rollback, pause new Bird assignments and resolve outstanding sends before restoring the old route. Keep both historical message references until the application's retention policy allows their removal.