# 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.

## Map receiving and reply identities

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](https://resend.com/docs/dashboard/receiving/reply-to-emails).

| Resend workflow                                 | Bird mailbox workflow                                                                                                   |
| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Receiving domain or account receiving subdomain | Create a dedicated Bird mailbox and test its actual address before changing how customers reach it.                     |
| `data.email_id` for the received API resource   | Save the new Bird `rem_` message ID with your application case; retain old IDs for archive access.                      |
| RFC `data.message_id` used in email headers     | Use Bird's `thr_` and `rem_` IDs for the thread reply operation. Do not submit an RFC Message-ID as a Bird resource ID. |
| Retrieve received content after notification    | Read the Bird thread message, including `extracted_text` when the worker needs the new text without quoted history.     |
| Build reply headers in the send request         | Call `email.threads.messages.reply`; the operation derives recipients and threading headers from the source message.    |
| Retrieve attachment metadata and a download URL | List Bird attachment metadata, then retrieve bytes through its authenticated thread-message attachment endpoint.        |

The receiving and attachment capabilities are documented in [Resend receiving](https://resend.com/docs/dashboard/receiving/introduction). If the application only needs to parse incoming mail, consider [Bird inbound email](/docs/guides/email/receiving-email) before introducing a mailbox.

## Keep the application case stable

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.

## Build the Bird workflow

Start with the complete [Node.js support inbox](/docs/get-started/quickstarts/typescript/mailboxes) or [Python support inbox](/docs/get-started/quickstarts/python/mailboxes). 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](/docs/guides/mailboxes/events-and-attachments). 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.

## Verify replies and retries

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](/docs/guides/idempotency). Keep a business outcome such as a completed refund separate from the acknowledgement email.

## Move inbound routing

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](/docs/guides/email/migrate/resend).

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.

## Next steps

- [Compare Bird and Resend](/products/mailboxes/compare/bird-vs-resend)
- [Mailbox integration and retention](/docs/guides/email/mailboxes)
- [Resolve receiving and reply problems](/docs/guides/mailboxes/troubleshooting)
- [All mailbox migration guides](/docs/guides/mailboxes/migrate)
- [Mailbox resources](/mailboxes/resources)
- [Email pricing](/products/email/pricing)

## Related resources

- [Getting started with email](/learn/email/getting-started-with-email) (video)
- [Email](/email-api) (product)
- [Build your first integration](/learn/paths/integration) (course)
- [Send your first email](/docs/get-started/send-your-first-email) (docs)

[Get an implementation brief](/learn/workspace?topic=email)