Skip to content
Skip to main content

How to forward an email

Last updated:

Forwarding an email means sending the original message to a new set of recipients, with the original content quoted below your note and the attachments carried along. There’s no dedicated forward field in the v3 API, and that surprises people. You compose a new message yourself, set fresh to recipients, prefix the subject with Fwd:, and include the original body and files.

This recipe shows the full forward composition against /messages/send: how to fetch the original message, build a quoted body, re-attach files, and why forwarding differs from a reply. The same flow works whether a person triggers it in your UI or an automated process forwards an inbound message to a downstream team.

Forwarding and replying both call POST /v3/grants/{grant_id}/messages/send, but they set different fields. A reply uses reply_to_message_id to thread under the original conversation and usually goes back to the original sender. A forward sends the original content to brand-new recipients you choose, so you leave threading off and compose the quoted content into the body yourself.

Per the Messages API reference, reply_to_message_id is the ID of the message you’re replying to. For Gmail and Microsoft Graph it’s the provider message ID, and for IMAP it’s the RFC822 Message-ID header. The API reads that message and stamps In-Reply-To and References headers so the outbound nests in the thread. That’s exactly what you don’t want when forwarding, because a forward starts a fresh conversation with people who weren’t on the original. So for a true forward you omit reply_to_message_id, set new to recipients, and put the quoted original into the body. If you need a reply instead, see How to reply to an email thread.

Before you can forward an email, you need its content: the subject, the body, the sender, and the list of attachments. Fetch the message by ID with GET /v3/grants/{grant_id}/messages/{message_id}. The response includes an attachments array where each of the 4 core fields per file (id, filename, content_type, and size in bytes) describes the file, but not the file bytes themselves.

The body field holds the original HTML, which you’ll quote in the forwarded message. The attachments array lists files by ID, but each file needs its own download before you can re-attach it, so a message with 2 attachments means 2 requests after this fetch. Keep the from, date, to, and subject values too, since a clean forward header repeats them at the top of the quoted body.

A forward is a new message with new to recipients and a body that holds your note plus the quoted original. The request below sends through POST /v3/grants/{grant_id}/messages/send with the subject prefixed Fwd: and an HTML body that reproduces the original headers and content. There’s no reply_to_message_id, so the message starts a fresh conversation rather than threading.

The API doesn’t add the subject prefix for you, so set Fwd: yourself and skip it when the original subject already starts with one. Build the quoted header from the original from, date, and subject so recipients see where the message came from. A body-only forward like this one stays well under the 3 MB JSON request limit, and attachments are what push you toward it. The new message lands in the sender’s Sent folder like any other outbound email.

Attachments don’t travel automatically. The forwarded message only includes files you put in its attachments array, so you download each original file, then attach it to the send request. Download with GET /v3/grants/{grant_id}/attachments/{attachment_id}/download, which requires the message_id of the message the attachment belongs to as a query parameter.

Base64-encoded attachments in a JSON request work up to 3 MB total. For files larger than that and up to 25 MB, switch to multipart/form-data, which the send attachments recipe covers step by step. Watch out for inline images: if the original body references a cid: source, re-attach that file with a matching content_id so the image renders instead of breaking.

A few details trip people up when they build forwarding on top of /messages/send. Most stem from the fact that you compose the forward yourself rather than calling a single forward endpoint, so you re-add every piece of the original you want carried over. The size limit is the most common surprise: an original message with a 10 MB attachment can’t ride along in a base64 JSON request.

  • Don’t set reply_to_message_id on a forward. That field threads the message under the original conversation and references the original sender. A forward goes to new recipients and should start fresh, so leave it out. Use it only when you mean to reply to the thread.
  • Sanitize the quoted body before you send. The original body is raw provider HTML and can carry remote tracking images or broken cid: references. Strip or rewrite anything you don’t want forwarded, especially when an automated process forwards inbound mail from an unverified source.
  • Re-attach inline images with their content_id. Inline images use a cid: reference in the HTML and a matching content_id on the attachment. Drop the content_id and the image shows as a broken link in the forwarded copy.
  • Carry CC and BCC with intent. A forward doesn’t copy the original cc list. Add cc or bcc only if you want those people on the new message, since forwarding to a fresh recipient set is usually the point.
  • Mind the total payload size. The base64 JSON path caps at 3 MB. If the combined attachments exceed it, switch to multipart or drop large files and link to them instead.