Notifications
Emails and push notifications that keep referrers and referees updated on referral status
Invitebase can be configured to send push notifications and emails when invites convert, when money is waiting, or when welcome rewards are active.
For documentation on sending messages to you as the business owner (Slack, webhooks, email alerts), see Owner alerts.
Notification triggers
Notifications to your users (referrers and referees) hang off the referral lifecycle: when the state machine records a transition, Invitebase resolves the audience, checks their preferences, and dispatches to email and push.
| Trigger | Recipient | Fires when |
|---|---|---|
| Referral signup | Referrer | Someone signs up with their code (referral reaches signed_up) |
| Referral validated | Referrer | The referral passes qualification gates and fraud checks |
| Reward unlocked | Referee | Their welcome reward (free month, in-app unlock) becomes active |
| Payout available | Referrer | A reward reaches payable state and is claimable |
| Milestone reached | Referrer | They cross a tier threshold ("5 of 10 referrals toward the hoodie") |
Delivery guarantees worth knowing:
- Exactly once per moment. Retried transitions and duplicate events never double-notify.
- Honest copy by state. The signup notification says the reward is pending until the referral qualifies — it never implies money is earned before validation.
- Holds are respected. A payout still inside its hold window does not trigger "payout available" until it's released.
- Batching. Multiple payouts landing together collapse into one message, not N.
- Mode-aware. Test-mode activity never notifies real users; test emails go to your org's own address only.
Email integration is handled directly from Invitebase with your app's branding — your app name, logo, and accent color. Email integration requires connection of a custom domain name — or, if you already send email through Resend, connect your existing account and domain via the Resend integration instead.
Push
Push notifications can be configured through two delivery modes, chosen per app in Settings. Either way, per-user preferences are honored before every send.
1. Invitebase managed (default)
No push infrastructure needed on your side. The Invitebase SDK handles push notifications automatically. Two things wire it up:
- Upload your push credentials in Settings: an APNs authentication key (
.p8, with its key ID and team ID) for iOS, and an FCM service-account key for Android. - Forward the device token from your app. Register for remote notifications as usual, then hand the token to the SDK with
setPushToken(token)any time afterconfigure(). The SDK attaches it to the current user — anonymous or identified — and keeps it current across token rotations.
Tokens are stored per user, per device: a referrer with two devices gets the push on both, and stale tokens are pruned on APNs/FCM feedback.
2. Bring your own push provider (webhook)
Bring-your-own-push delivery is planned but not yet available — notification.due is not yet part of the event catalog. Today, use Invitebase-managed push (above).
If you already have a push system, you'll be able to keep it: Invitebase will deliver a signed notification.due webhook carrying the recipient (your external_id), the trigger, and the rendered content — title, body, deep link — and your backend sends it through APNs/FCM yourself. Device tokens and push credentials stay entirely on your side; no credential upload, no setPushToken. Opted-out users never fire notification.due, so preference handling stays on Invitebase. Standard webhook semantics apply: verify the signature, dedupe on the event id, return a 2xx.
Customizing templates
Notification and email templates are edited in the end-user surface editor alongside your invite pages: subject lines and body copy per trigger, with the shared theme (logo, colors) applied automatically and a live preview rendered with sample data. Template changes are versioned and audit-logged.
Per campaign or app, each trigger can be toggled on or off — run signup notifications without milestone emails, or turn everything off and drive messaging yourself from webhooks.
Preferences and opt-out
Preferences are stored per user, per channel (email/push), and checked before every dispatch. Both channels default to on; opt-outs survive re-identification and new devices.
Users can opt out of referral emails and notifications at any point - configured through the SDK or API.
await invitebase.setNotificationPreferences({ email: false, push: false });try await Invitebase.setNotificationPreferences(
NotificationPreferences(email: false, push: false)
)lifecycleScope.launch {
Invitebase.setNotificationPreferences(
NotificationPreferences(email = false, push = false)
)
}const invitebase = useInvitebase();
await invitebase.setNotificationPreferences({ email: false, push: false });await Invitebase.setNotificationPreferences(
NotificationPreferences(email: false, push: false),
);curl https://api.invitebase.com/v1/referrers \
-H "Authorization: Bearer $INVITEBASE_SECRET_KEY" \
-H "Content-Type: application/json" \
-d '{
"external_id": "usr_123",
"notification_preferences": { "email": false, "push": false }
}'Full reference: setNotificationPreferences in the SDK, or notification_preferences on the create-or-identify upsert from your backend.
Compliance built in
Invitebase messages your users on your behalf, so the baseline is handled regardless of what you build:
- Every email carries a one-click unsubscribe (link plus
List-Unsubscribeheader) that flips the same per-user email preference. - Bounces and spam complaints feed an automatic suppression list.
- Per-app rate limits prevent a buggy integration from blasting users.