I’m posting here since we no longer have access to support channels per the changes announced yesterday. We believe this is a bug in Nylas webhook delivery, and if so, it’s a serious one.
Issue: We have customers repeatedly reporting missing emails in our system. After investigation, it appears we’re not receiving webhooks we expected based on how we understood the webhook system to work.
What we’re seeing:
Missing message.created webhooks - We’ve identified numerous messages where Nylas logs show only message.updated events were sent, with no corresponding message.created event. We expected each new message to generate a message.created event, although the documentation isn’t definitive on this.
Workaround challenges - We’ve been attempting to use message.updated as a workaround for missing message.created events, but this isn’t reliable since not all messages will have an update event.
Impact: This results in emails being completely missing from our system, causing significant customer complaints.
I’d prefer not to post customer email addresses, grant IDs, and message IDs on a public forum. If someone from Nylas engineering could reach out, I can provide specific examples and logs to help investigate. We’re open to exploring if there’s something on our end, but the pattern suggests a webhook delivery issue.
The quick summary is that some email providers don’t differentiate between creation and update notifications so Nylas is left to try to programmatically determine which webhook trigger to send out. And while we catch most, there are edge cases where the wrong one will be sent.
We recommend using both message webhook triggers and keeping a local cache of messages. If you get a webhook regarding a message ID that you don’t have cached, you can safely assume it is a new message.
Please let us know if you did not receive any message webhook at all for a new message and we can investigate further.
I’ve reviewed both the webhook documentation and webhook quickstart guide and found no mention of this behavior. I may have missed it, but I think this is critical information which should be in the main webhook documentation, not just a knowledge base article. The main docs state webhooks have “at least once” delivery guarantee, which implies we’ll get at least one message.created per message. Now it seems the true meaning is “if we’re able to distinguish a created event, then it will be delivered at least once” - but I think you can see why this would be interpreted as “we can rely on getting a message.created event for each message.”
Per the KB article, the underlying architectural change allowed you to eliminate your message storage layer. While this may have simplified your infrastructure, it shifts significant complexity to customers. We have no need to handle message.updated events otherwise - we don’t care about read status or folder changes. The only reason we’d need to process these events is to work around missing message.created webhooks. This means we now need to handle multiple message types per message and process significantly more webhook traffic.
Your recommendation to keep a local cache essentially asks us to solve a generic email problem that isn’t specific to our business domain. This feels like exactly the type of provider-specific complexity that Nylas’s value proposition is supposed to abstract away. While our existing system would technically work without this caching layer, we have fairly complex logic that determines if a message is relevant to our platform. We don’t want to run this expensive processing multiple times for each underlying message, only to reject it at the end as a duplicate, so we’ll need to build in such a layer that stores at least recently seen message IDs to short-circuit and discard duplicates. I recognize there were security reasons for eliminating the message storage layer as well, but the point remains - this architectural decision shifts complexity to customers.
As a minor point, the KB article doesn’t mention Microsoft specifically - it only mentions “Graph”. When I see “Graph” I don’t think “Microsoft” since the whole purpose of Nylas is to abstract away details of underlying APIs. Would suggest docs explicitly say “Microsoft Graph” for clarity. FYI we use Nylas exclusively with Microsoft at this point so I was looking for an explicit Microsoft reference.
We’re still wary that we may be missing webhooks altogether, but we need to investigate more thoroughly and it will take time to collect data. We’ll follow up if we find there are messages for which we don’t receive either event type.