Thanks for the response. Some feedback:
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.
Also, I noticed this unresolved thread on the same topic: Some webhook events missing from logs / never received by webhook url