Nylas Attachments

Custom IMAP attachment downloads consistently fail with 504 provider_error

Hello,

We are developing an event/workflow-management application that uses the Nylas EU API. We are currently using the free Developer Sandbox and intend to move to a paid production plan before launch.

We have connected a Purelymail mailbox using Nylas custom IMAP/BYO authentication.Purelymail is being used only as a temporary test mailbox during development. It is not necessarily our intended production email provider. We need to establish whether this failure is specific to Purelymail, applies more broadly to custom IMAP providers, or is related to the Developer Sandbox.

Configuration

  • Nylas API region: EU
  • Provider: imap
  • Authentication: POST /v3/connect/custom
  • IMAP host: imap.purelymail.com
  • IMAP port: 993
  • SMTP host: smtp.purelymail.com
  • SMTP port: 465
  • Username: full mailbox address
  • Test attachment: PDF, approximately 26 KB
  • Application implementation: Node.js using direct HTTPS requests to the Nylas v3 API

What works

  • Creating the custom IMAP grant
  • Retrieving recent messages
  • Retrieving individual messages
  • Reading sender, recipient, subject and message body
  • Receiving attachment metadata
  • Receiving the attachment ID, filename, MIME type and size
  • Sending replies through the connected mailbox
  • Disconnecting and creating a fresh grant

Problem

Downloading the attachment bytes consistently fails using:

GET /v3/grants/{grant_id}/attachments/{attachment_id}/download?message_id={message_id}
Authorization: Bearer [REDACTED]
Accept: application/octet-stream

Nylas responds with HTTP 504:

{
  "error": {
    "type": "provider_error",
    "message": "IMAP provider closed connection, please try again later."
  }
}

Troubleshooting already completed

  • Tested multiple newly sent emails.
  • Tested multiple PDF attachments.
  • Confirmed the attachment is only approximately 26 KB.
  • Repeated the request after waiting.
  • Closed the desktop email client to avoid competing IMAP connections.
  • Disconnected and reconnected the mailbox.
  • Created and tested a fresh Nylas grant.
  • Retrieved the full message immediately before requesting the attachment.
  • Tested the normal cached attachment download.
  • Tested direct IMAP retrieval:
GET /v3/grants/{grant_id}/attachments/{attachment_id}/download?message_id={message_id}&query_imap=true
  • Tested retrieving the complete message using:
GET /v3/grants/{grant_id}/messages/{message_id}?fields=raw_mime

Both attachment modes and the raw_mime request return the same 504 provider_error. Normal message retrieval and attachment metadata continue to work.

We also confirmed that imap.purelymail.com:993 and smtp.purelymail.com:465 are reachable.

The integration automatically retries the attachment request three times, but each attempt receives the same provider failure.

Questions

  1. Is attachment downloading from custom IMAP grants supported in the free Developer Sandbox?
  2. Is Purelymail known to be incompatible or partially compatible with Nylas custom IMAP attachment retrieval? If so, which inexpensive custom-IMAP provider would Nylas recommend for development testing?
  3. Does this grant or IMAP connector require any additional policy, scope or configuration for attachment downloads?
  4. Is query_imap=true the recommended option for Purelymail?
  5. Why would normal message retrieval work while attachment and raw-MIME retrieval cause the provider to close the connection?
  6. Is there another supported endpoint or fallback for downloading attachment bytes from a custom IMAP grant?
  7. Would moving to a paid plan change this behaviour, or is this unrelated to plan level?

We have redacted the application ID, API key, grant ID, message IDs and attachment IDs because this is a public forum. We can provide Nylas request IDs privately if a Nylas employee provides a secure method.

Thank you.

Hello. Our Support team has reached out to you via email to continue this investigation. Please check your mailbox for our message.