Keep API message IDs separate from email threading headers

Store the API resource tuple

For application work, keep organization_id, inbox_id, thread_id and message_id together when those fields are available. Your API route uses email_id as its path parameter while serialized messages identify the resource with message_id. Naming this mapping explicitly avoids storing the subject as a key or losing the inbox context needed for a later read. IDs describe resources inside an authorization boundary. They do not grant access on their own, and copying a message ID into another tenant’s work item should never switch the credential used by your client.

Do not confuse a subject with a conversation

Two unrelated messages can share a subject, and one continuing exchange can change its subject. Use the thread resource returned by the API rather than constructing your own grouping from Re: prefixes. GET thread detail returns messages in ascending order, which is useful for a timeline but still requires reading who said what. If your application merges multiple threads into a business case, represent that merge explicitly in your own records. Do not overwrite the original API thread IDs simply because a model decides the messages sound related.

Preserve mail-level references as evidence

RFC 5322 defines Message-ID, In-Reply-To and References fields for message identification and replies. Lupin message objects expose in_reply_to, references and headers alongside API resource identifiers. Keep external header values as received evidence without assuming they share the same namespace as your application’s IDs. In Lupin’s reply handlers, conversation references are derived from the selected source message. Prefer those reply routes or a reply draft to manually composing arbitrary threading headers when you intend to continue an existing exchange.

Treat forwards as a different relationship

A direct forward starts a new thread while embedding source context, so its business relationship to the original email is different from a reply’s conversation membership. Save an explicit source_message_id in your local action record if your workflow needs that provenance. A forwarded body can contain lines that look like headers, but quoted text is not authenticated routing metadata for the new message. Likewise, an email that claims to reference a private thread does not prove the sender is entitled to read it. Recheck the owned source resource before sharing context.

Design reconciliation around stable records

Use the API message identity for local processing deduplication and the saved operation key for external-send retry recovery. A mail-level Message-ID alone is insufficient as a global tenant-independent database key because your application must also preserve ownership and ingestion context. When a source is deleted or unavailable, retain a clear missing-source state rather than fetching a similarly titled message. Your next step is a fixture with repeated subjects, an ordinary reply and a forward, then confirm that your case timeline keeps resource identity, external headers and business relationships separate.

Preserve namespace in exports

When exporting a case timeline, include the workspace and inbox mapping with each API message reference. A bare msg_ identifier in a spreadsheet or support note loses the ownership context needed to retrieve it safely later. Treat external Message-ID headers as separate fields so an import script cannot accidentally substitute them for API route identifiers.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin message fields and replies ↗Checked 2026-11-05
• Lupin thread detail ↗Checked 2026-11-05
• RFC 5322 identification fields ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.