Best approach for sending notifications when new community content is published?

Question and Answers
1

Hi everyone,

I’m integrating Nylas into a web application and I’m looking for some advice on the overall notification workflow rather than a specific API issue. The application is a community website for download Geometry Dash IPA players where users can follow certain content categories, authors, and discussion topics. Whenever new content is published (for example, a new guide, walkthrough, or community announcement), I’d like subscribed users to receive an email notification.

I’m trying to decide how much of this workflow should be event-driven.

My current idea is:

  1. A new article is published.
  2. The application emits an internal event.
  3. A background worker determines which users are subscribed.
  4. Nylas is used to send the email notifications.

I’m also considering using webhooks to track delivery events and update our notification status so we know whether an email was delivered, bounced, or failed.

My questions are:

  • Is this generally the approach people are taking with Nylas, or am I adding unnecessary complexity?
  • Do you typically send emails immediately after the publish event, or queue everything and process it asynchronously?
  • Are there any webhook events that you found especially useful for keeping notification records accurate?

At the moment, the expected volume isn’t huge, but I’d like to build something that can scale without having to redesign the entire notification system later.

I’d really appreciate hearing how others have structured similar workflows using Nylas. Thanks!

2

Hello,

Great question, and the architecture you’ve outlined is exactly the shape we’d recommend, you’re not overengineering this.

Event-driven vs one-off complexity:
Event → queue/worker → Nylas send → webhook-based status tracking is the standard pattern for this kind of fan-out notification system. Preferring webhooks over polling for status tracking is a core Nylas best practice, not something specific to your case.

Queue it, don’t send synchronously on publish:
A few reasons to process asynchronously rather than sending immediately when the publish event fires:

  • Provider-side send limits are tighter than most people expect. Google caps at 2,000 messages/day per grant, and Microsoft caps at 30 messages/min per grant. If notifications fan out from a single mailbox grant, a popular post could hit Microsoft’s limit in under a minute. See rate limits.

Webhooks for delivery, failure, and bounce tracking:

  • message.send_success and message.send_failed only fire for Scheduled Send messages, meaning the message must be sent with a send_at parameter set. A plain immediate POST /v3/messages/send will not get an async webhook confirming delivery, you only get the synchronous API response at send time.
  • For bounce tracking specifically, there is a dedicated message.bounce_detected trigger, which fires when Nylas detects a Non-Delivery Report (NDR) in the sender’s inbox for a message sent via Nylas. You do not need to parse bounce notifications out of regular inbox messages yourself.

Practical recommendation: send every notification through Scheduled Send, even with send_at set just a few seconds in the future, so you get message.send_success/message.send_failed for delivery status, and add message.bounce_detected for bounce tracking. That combination should cover delivered, failed, and bounced states without you needing to poll or parse inbox messages manually.

Other useful docs:

Hope this helps, feel free to follow up with any questions.

Many thanks,
Samuel R.
Support Engineer, Nylas