Description
The first version of push in an app is always easy: call APNs, store the token, send. The trouble starts in month two. A user replaces their phone and the old token fails forever. You want to reach only "paying users who trained three times this week", so you write the query yourself. Someone turned marketing notifications off in settings, and now every send site has to remember that. APNs returns the occasional 503 and you write retry logic. By the time all of it is handled, a notification system nobody wants to maintain is living inside your product code.
BuzzKit lifts that layer out. You still bring your own provider keys — it never takes over your sending account — and it handles the tedious parts: subscriber and device sync, targeting by attribute and behaviour, per-user preferences, scheduling and workflows, retries and delivery receipts, all through one API and one dashboard.
It is designed to be integrated once and driven by events afterwards. The SDK keeps users and devices in sync, your app and backend report what happened, and workflows decide what goes out and when. iOS push is supported today, with Android, email and SMS on the roadmap as connectors sharing the same multi-channel core. Use the hosted service at buzzkit.dev or self-host the same code.
Visual workflows: Triggers, branches, waits and sends laid out as a flow. "One day after the trial starts, nudge anyone who has not opened the app" is a few clicks in the dashboard rather than a release.
Behavioural targeting: Segments combine attributes, event counts and recency — plan is pro, completed three workouts in the last 7 days, active within 30 days — and show the matching audience size as you build them.
Subscriber and device sync: The SDK maintains the mapping between users and device tokens through phone changes, uninstalls and revoked permissions, so dead tokens stop being your problem.
Preferences and topics: Users subscribe and unsubscribe per topic; BuzzKit stores those preferences and enforces them at send time so your code does not have to.
Delivery receipts and event stream: Reachable, sent, pending and failed counts are recorded per message, with a Tinybird-backed event stream you can follow down to a single subscriber.
Bring your own keys, self-host: Provider credentials stay yours and are stored encrypted; the core is AGPLv3 and deploys on your own Cloudflare Workers, PostgreSQL and Tinybird.
Typed SDK: The server SDK and the API share one schema, so workflows, sources and import formats validate against the same definitions on both sides and interface changes surface at compile time.
BuzzKit lifts that layer out. You still bring your own provider keys — it never takes over your sending account — and it handles the tedious parts: subscriber and device sync, targeting by attribute and behaviour, per-user preferences, scheduling and workflows, retries and delivery receipts, all through one API and one dashboard.
It is designed to be integrated once and driven by events afterwards. The SDK keeps users and devices in sync, your app and backend report what happened, and workflows decide what goes out and when. iOS push is supported today, with Android, email and SMS on the roadmap as connectors sharing the same multi-channel core. Use the hosted service at buzzkit.dev or self-host the same code.
Features
Visual workflows: Triggers, branches, waits and sends laid out as a flow. "One day after the trial starts, nudge anyone who has not opened the app" is a few clicks in the dashboard rather than a release.
Behavioural targeting: Segments combine attributes, event counts and recency — plan is pro, completed three workouts in the last 7 days, active within 30 days — and show the matching audience size as you build them.
Subscriber and device sync: The SDK maintains the mapping between users and device tokens through phone changes, uninstalls and revoked permissions, so dead tokens stop being your problem.
Preferences and topics: Users subscribe and unsubscribe per topic; BuzzKit stores those preferences and enforces them at send time so your code does not have to.
Delivery receipts and event stream: Reachable, sent, pending and failed counts are recorded per message, with a Tinybird-backed event stream you can follow down to a single subscriber.
Bring your own keys, self-host: Provider credentials stay yours and are stored encrypted; the core is AGPLv3 and deploys on your own Cloudflare Workers, PostgreSQL and Tinybird.
Typed SDK: The server SDK and the API share one schema, so workflows, sources and import formats validate against the same definitions on both sides and interface changes surface at compile time.
