Skip to content

How to list IMAP email threads

Not every email provider is Google, Microsoft, or Yahoo. Thousands of organizations run their own mail servers, and services like Zoho Mail, Fastmail, AOL, and GMX all support IMAP. Nylas connects to any standard IMAP server and constructs conversation threads from message headers, giving you a conversation view through the same Threads API you’d use for Gmail or Outlook.

This guide covers listing threads from generic IMAP accounts and explains how Nylas builds threads without native provider support.

Why use Nylas for threads instead of IMAP directly?

Section titled “Why use Nylas for threads instead of IMAP directly?”

The IMAP protocol has no built-in concept of conversation threading. RFC 5256 defines a THREAD extension, but very few servers implement it, and even those that do offer limited grouping algorithms. To build a conversation view yourself, you’d need to parse In-Reply-To and References headers from every message, group them by conversation chain, handle subject-line variations, maintain persistent socket connections, and deal with MIME parsing.

Nylas does all of that behind a REST API. The Threads API returns pre-grouped conversations with participant lists, read state, and the latest message content. Your code works across IMAP, Gmail, Outlook, Yahoo, and iCloud without modification.

You’ll need:

  • A Nylas application with a valid API key
  • A grant for an IMAP email account
  • The IMAP server hostname and port for the provider (e.g., imap.example.com:993)

New to Nylas? Start with the quickstart guide to set up your app and connect a test account before continuing here.

The generic IMAP connector works with any standard IMAP server. Nylas supports two authentication flows:

MethodBest for
Hosted OAuthProduction apps where Nylas collects IMAP credentials through a guided flow
Bring Your Own (BYO) AuthenticationCustom auth pages where you collect IMAP host, port, and credentials directly

Most IMAP providers require app passwords instead of the user’s regular login password. This is especially true for providers with two-factor authentication enabled. See the app passwords guide for provider-specific instructions.

The full setup walkthrough is in the IMAP authentication guide.

Make a List Threads request with the grant ID. By default, Nylas returns the most recent threads. These examples limit results to 5:

The response includes a latest_draft_or_message object with the most recent message’s content. The same code works for Google, Microsoft, and Yahoo accounts.

You can narrow results with query parameters. Here’s what works with IMAP accounts:

ParameterWhat it doesExample
subjectMatch on subject line?subject=Weekly standup
fromFilter by sender[email protected]
toFilter by recipient[email protected]
unreadUnread only?unread=true
inFilter by folder or label ID?in=INBOX
received_afterAfter a Unix timestamp?received_after=1706000000
received_beforeBefore a Unix timestamp?received_before=1706100000
has_attachmentOnly results with attachments?has_attachment=true

Here’s how to combine filters. This pulls threads with unread messages from a specific sender:

IMAP providers support the search_query_native parameter, which maps to the IMAP SEARCH command defined in RFC 3501. Like Yahoo and iCloud, generic IMAP lets you combine search_query_native with any other query parameter.

Not all IMAP servers support the SEARCH operator. If search_query_native returns a 400 error, the provider doesn’t support it. Fall back to standard query parameters (subject, from, to, etc.) instead.

See the search best practices guide for more on search_query_native across providers.

The generic IMAP connector is the most flexible provider type. It works with nearly any mail server, but that flexibility comes with some threading-specific trade-offs.

IMAP servers don’t provide native thread grouping (despite RFC 5256 defining a THREAD extension, very few servers implement it). Nylas builds threads by analyzing In-Reply-To and References headers on each message, combined with subject-line matching. This approach works regardless of whether the server supports the THREAD extension.

Thread quality depends on the email clients involved in the conversation. Modern clients (Gmail, Outlook, Apple Mail, Thunderbird) set proper In-Reply-To and References headers. Older or misconfigured clients may not, which can result in messages that should be grouped together appearing as separate threads.

Nylas maintains a rolling cache of messages from the last 90 days for IMAP-based providers. Threads are built from cached messages, so conversations that span beyond 90 days may appear incomplete. The message_ids array only includes messages within the cache window.

To access older messages directly (not as threads), use query_imap=true on the Messages API. The Threads API does not support query_imap.

IMAP servers use a UIDVALIDITY value to track whether message UIDs in a folder are still valid. If the server changes this value (due to a folder rebuild or migration), Nylas re-indexes the folder. During re-indexing, threads may temporarily appear incomplete or split.

If you encounter UIDVALIDITY errors, check the IMAP troubleshooting guide for workarounds.

Thread-level fields are computed from all cached messages in the conversation:

  • unread is true if any message in the thread is unread
  • starred is true if any message is starred
  • has_attachments is true if any message has attachments
  • participants is the union of all senders and recipients
  • earliest_message_date reflects the oldest cached message, not necessarily the start of the conversation

IMAP folder names are set by each provider. Nylas maps common folders using RFC 9051 standard attributes, but always use the List Folders endpoint to discover the actual folder names for each account. This matters when filtering threads with the in parameter.

Nylas monitors the Inbox and Sent folders with IMAP idle connections for near-real-time change detection. Other folders are checked periodically. Thread updates from Inbox activity appear quickly, while threads in custom folders may take a few minutes to update.

The Threads API returns paginated responses. When there are more results, the response includes a next_cursor value. Pass it back as page_token to get the next page:

Keep paginating until the response comes back without a next_cursor.