I’m having trouble with messages sent through the Gmail API. When I send drafts using the API, the sent messages show up in my Sent folder but I can’t open them when using the new Gmail interface. I get an error saying “The conversation that you requested could not be loaded.”
The weird thing is that recipients can open these messages just fine on their end. Also, if I switch back to the classic Gmail interface, I can view the sent messages without any problems.
Here’s how I reproduce this issue:
Create a draft message in Gmail
Get the draft ID using GET https://www.googleapis.com/gmail/v1/users/me/drafts
Send it via POST https://www.googleapis.com/gmail/v1/users/me/drafts/send with payload {"id": "<draftId>"}
Try to open the sent message in new Gmail UI - it fails
Switch to classic UI - it works fine
I noticed something interesting though. When someone replies to these broken sent emails, they suddenly start working in the new UI too. This makes me think the API might be missing some data that gets added when the conversation gets updated normally.
The browser console shows this error: Error: Ppa No message loaded when we received the DETAILED_CONVERSATION_MESSAGES_LOADED event.
Has anyone else run into this problem? Any ideas what might be causing it?
Yeah, this is a known Gmail API bug with message threading in the new interface. I ran into the same thing about six months back when building our company’s automated email system. The API doesn’t set complete thread metadata when sending messages. The new Gmail interface is way pickier about proper conversation threading than the old one was. When someone replies to your message, Gmail fills in the missing thread info automatically - that’s why they show up after replies. I fixed this by ditching the drafts endpoint and using the messages send endpoint instead. Make sure you include proper Message-ID and References headers so Gmail has all the threading data upfront. The classic interface lets you get away with incomplete metadata, but the new UI won’t display messages unless the conversation structure is perfect.
Yeah, this is a known Gmail API threading bug that’s been driving developers crazy since their interface update. Hit the same issue building email automation for our CRM. The problem is drafts.send doesn’t fill in all the conversation metadata that Gmail’s new UI needs to display messages properly. Here’s what worked for me: grab the draft’s threadId and messageId before sending, then immediately call messages.modify after the API send to force the thread association. Gmail’s new interface is way pickier about conversation integrity than the old one. The fact that replies fix it proves this theory - when someone responds, Gmail automatically rebuilds the thread with complete metadata. That DETAILED_CONVERSATION_MESSAGES_LOADED error you’re seeing means the frontend can’t find the message in its expected thread.
This threading mess is exactly why I automated our entire email pipeline last year. Gmail’s API draft endpoint has weird quirks with conversation metadata that completely break in the new UI.
I got tired of wrestling with API headers and Message-ID formatting, so I built a workflow that handles all the email logic automatically. No more missing thread data or broken conversations.
Best part? You can set up everything visually. Draft creation, sending, error handling, retry logic for failed sends. It automatically includes all the proper headers Gmail needs for threading.
I’ve been running hundreds of automated emails daily through this setup for months. Zero threading issues, works perfectly in both Gmail interfaces. Way easier than debugging API calls and manually building RFC headers.
The workflow approach also gives you better monitoring. You can see exactly which emails failed and why, plus automatically retry them.
Had this exact problem with email automation for client notifications. Gmail API handles conversation threading differently between drafts.send and messages.send - that’s your issue right there. I switched to messages.send and manually built the RFC 2822 headers (Message-ID and In-Reply-To). The new Gmail interface is way pickier about threading than the old one. Here’s a trick that helped: add a References header even on the first message in a thread. Gmail uses this to index conversations properly. That browser console error means the frontend can’t match your message to its thread - confirms the drafts API isn’t sending complete threading metadata.
ugh, same thing happened to me last month! super frustrating bug. what worked for me was adding a custom x-gmail-thread-id header when sending through the api. the new ui seems to need this extra metadata that the draft endpoint doesn’t include automatically. you can grab the thread id from the original draft response and manually add it to your send request. it’s a bit of a hack but completely solved the viewing issue for me.
I encountered the same issue when migrating our notification system earlier this year. The drafts.send endpoint of Gmail API creates messages with broken conversation metadata, which disrupts threading in the new UI. What resolved it for me was abandoning drafts.send and employing a two-step approach instead. I first retrieved the message content using drafts.get, then created a new message utilizing messages.send with the correct RFC headers. It’s crucial that your Message-ID header adheres to Gmail’s expected format and that you include a proper Date header with the correct timezone. The new UI is much stricter about conversation structure compared to the old interface, which explains why recipients can access these messages without issues—as their email clients are less strict about threading metadata. The browser error you’re seeing further indicates that the frontend struggles to properly index your message in the conversation thread.