I’m having trouble with messages I send using the Gmail REST API. When I send draft emails through the API, they show up in my Sent folder but I can’t open them when using the new Gmail interface.
Here’s what happens:
- Create a draft message in Gmail
- Use
GET https://www.googleapis.com/gmail/v1/users/me/drafts to get the draft ID
- Send it with
POST https://www.googleapis.com/gmail/v1/users/me/drafts/send using {"id": "<draft_id>"}
- Try to open the sent message in the new Gmail UI - it fails with error
"The conversation that you requested could not be loaded"
The weird part is that recipients can open these emails just fine. Also, if I switch back to the classic Gmail interface, I can view the sent messages without any problems.
I noticed something interesting - when someone replies to these broken 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 issue? Any ideas what might be causing it?
This sounds like a metadata sync issue between Gmail’s API and the new interface. I’ve hit similar problems building email automation systems.
The new Gmail UI probably expects certain conversation properties that don’t get set right when you send drafts via API. The classic interface doesn’t care about incomplete metadata.
Try this - skip the drafts endpoint and send messages directly with messages.send API. Structure it like this:
POST https://www.googleapis.com/gmail/v1/users/me/messages/send
{
"raw": "<base64-encoded-message>"
}
Make sure your raw message has proper MIME headers - especially Date, Message-ID, and From fields. Gmail generates these way better when you send directly instead of going through drafts.
Also check if you’re setting threadId when creating drafts. If the draft doesn’t have proper thread association from the start, the new UI won’t know how to display it in conversation view.
Replies fixing the issue confirms this is a conversation threading problem. Gmail rebuilds thread metadata when new messages arrive, which patches the missing data.
yeah, i faced this too. after sending drafts via the api, add like a 500ms delay b4 sending. it helps the new ui load properly. also, try refreshing your browser after sending, sometimes it goes wonky and needs that fix.
Had the same issue about six months back with an automated email system. Turned out Gmail handles conversation threading differently for API-sent messages vs. manually written ones. Fixed it by making sure my drafts had proper Message-ID and References headers before sending. When you create drafts through the API, Gmail sometimes skips generating the conversation metadata that the new UI needs. The old interface doesn’t care as much about missing headers. Check the raw headers on a working email vs. your API ones - you’ll see the threading headers are different. When people reply to your broken emails, Gmail fills in the missing conversation data automatically, which is why they work after that. I had to recreate my drafts with complete RFC-compliant headers instead of letting Gmail handle it during API sends.
This happens because Gmail API doesn’t initialize conversation view data properly when sending drafts. I ran into this last year migrating our company’s email automation from SMTP to Gmail API. Gmail’s backend treats API-sent drafts differently than messages composed in the UI during conversation creation. Here’s what fixed it for me: add a 2-3 second delay after creating the draft but before sending. This gives Gmail time to process the draft metadata fully. You can also try retrieving the draft again with the full format parameter before sending - forces Gmail to rebuild the conversation context. Better yet, ditch drafts entirely and use messages.send instead. When you send directly through messages.send, Gmail handles conversation threading way more reliably since it processes everything in one go rather than piecing it together across multiple API calls. Threading gets established correctly from the start.