OneSignal
Push notifications with segmentation, scheduling and campaign analytics.
The rule
This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.
Identity
OneSignal.login(userId)after sign-in,OneSignal.logout()after sign-out.- Missing
logout()leaves the device subscribed as the previous user, so the next person to sign in receives someone else's notifications. Treat it as part of the sign-out path, not a nice-to-have.
Permission
- Request in context, after your own explanation. On iOS the system prompt appears once per install and a decline is effectively permanent.
- Denied is a normal state — never block a feature on it.
Tags
- Non-personal attributes only: plan, locale, onboarding state.
- No email addresses, names, phone numbers or anything sensitive. This is a third-party store and purging it later is painful.
Payloads
- Notification content is visible on the lock screen and passes through Apple's and Google's infrastructure. Send an identifier and fetch details in-app.
Configuration
initialize()runs once at startup.- The plugin
modemust match the build:developmentAPNs in a production build fails silently. - The REST API key is server-side only — it can send to your whole audience.
Never
- Never expect this to work in Expo Go or a simulator.
- Never point a development build at the production OneSignal app.
6 formats, one per tool
Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.
---
description: OneSignal conventions
globs: ["src/services/notifications/**"]
alwaysApply: false
---
# OneSignal
## Identity
- `OneSignal.login(userId)` after sign-in, `OneSignal.logout()` after sign-out.
- Missing `logout()` leaves the device subscribed as the previous user, so the
next person to sign in receives someone else's notifications. Treat it as part
of the sign-out path, not a nice-to-have.
## Permission
- Request in context, after your own explanation. On iOS the system prompt
appears once per install and a decline is effectively permanent.
- Denied is a normal state — never block a feature on it.
## Tags
- Non-personal attributes only: plan, locale, onboarding state.
- No email addresses, names, phone numbers or anything sensitive. This is a
third-party store and purging it later is painful.
## Payloads
- Notification content is visible on the lock screen and passes through Apple's
and Google's infrastructure. Send an identifier and fetch details in-app.
## Configuration
- `initialize()` runs once at startup.
- The plugin `mode` must match the build: `development` APNs in a production
build fails silently.
- The REST API key is server-side only — it can send to your whole audience.
## Never
- Never expect this to work in Expo Go or a simulator.
- Never point a development build at the production OneSignal app.
Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.
What else this module writes
The rule is one file of several. Selecting OneSignal contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.
{{envPrefix}}ONESIGNAL_APP_IDrequiredOneSignal App ID for this environment.ONESIGNAL_REST_API_KEYoptionalSends notifications from your backend. Never ship in the app.Advisory history
Every time this rule turned out to be wrong, and what we did about it.
This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.
Pro tells you the day a correction lands that affects a repo you actually have.
See what Pro adds →Rules people add alongside this one
The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.