Hey, I work on a community chat product (web PWA, iOS, Android) and want to run notification orchestration and delivery on BuzzKit. The workflow engine looks great: onboarding sequences, "you still haven't seen this reply" nudges, re-engagement, etc, all of it timed per user
We already have an inbox and a permission model, and we want to keep both. Every notification in our product is gated on the user's access, which can change at any time. We want buzzkit to drive async and delayed delivery, but we need a way to filter by permission before a send
Pre-send eligibility callback
It would be great if before a send, buzzkit could optionally run an optional tenant-configured endpoint that processDeliveryBatch calls right before each provider send. Request carries the message payload, the subscriber's external id, and the platform. Response is one of deliver, skip (with a reason, recorded on the delivery), or defer (with a delay in seconds). If the callback fails, default to skip; a late notification beats one the recipient shouldn't have seen.
Anyone with a consent service, a preference center, or content-level authorization needs the same hook.
Web push
Also, is web push via fcm on your roadmap? Seems like it'd be easy to add
Happy to PR these two things if you're accepting
Hey, I work on a community chat product (web PWA, iOS, Android) and want to run notification orchestration and delivery on BuzzKit. The workflow engine looks great: onboarding sequences, "you still haven't seen this reply" nudges, re-engagement, etc, all of it timed per user
We already have an inbox and a permission model, and we want to keep both. Every notification in our product is gated on the user's access, which can change at any time. We want buzzkit to drive async and delayed delivery, but we need a way to filter by permission before a send
Pre-send eligibility callback
It would be great if before a send, buzzkit could optionally run an optional tenant-configured endpoint that
processDeliveryBatchcalls right before each provider send. Request carries the message payload, the subscriber's external id, and the platform. Response is one ofdeliver,skip(with a reason, recorded on the delivery), ordefer(with a delay in seconds). If the callback fails, default toskip; a late notification beats one the recipient shouldn't have seen.Anyone with a consent service, a preference center, or content-level authorization needs the same hook.
Web push
Also, is web push via fcm on your roadmap? Seems like it'd be easy to add
Happy to PR these two things if you're accepting