This is a particular issue for developers implementing & testing the system. Is there some kind of exemption for developers sending notifications to themselves? (EDIT: I’ve tested this and it seems like there is no limit for sending yourself notifications, at least for now. This may be something to note in the docs)
Additionally is there a limit for how many requests can be sent to different users at once. i.e can I send notifications to 100,000 users at the same time every week or will I be throttled for sending so many requests at once. The docs for OpenCloud do not mention if there is a limit imposed on the sending server.
We’re excited to share that the OpenCloud and Lua APIs are no longer limited to testing-only and that your Experience Notifications will now be delivered to users.
Now that the APIs have been fully released, you can find the Lua package available for download in the Studio Toolbox.
Creator Analytics will also become available shortly to track the performance of your notifications.
I’m happy to share that Creator Analytics for Experience Notifications is now live in the Creator Dashboard! You can access your analytics by visiting the Creator Hub (create.roblox.com) and clicking Manage Experience or Analytics on your experience’s tile. You can then find Notification Analytics under Engagement → Notifications by toggling the page from Creations to Analytics.
Please note that a minimum of 100 user impressions are required to be able to see notification performance, but the number of opted-in users will be immediately available. You can learn more about analytics in the Analytics section of the developer guides (Lua Creator Guide, OpenCloud Creator Guide).
I’m trying to include Experience Notifications inside of Obby Creator, but I’m experiencing some issues.
When I send a blank test notification, it works just fine! However, once I try to use a notification with a payload, it starts erroring. I’m not sure what I’m doing wrong. Do you have any ideas? Thank you!
For the obbyname I’m using the string “Test Obby Name”. Am I meant to JSONEncode the payload? It doesn’t say to do this on the creator docs.
EDIT: I was simply passing the string “Test Obby Name” into the parameters section, when I should have been passing {StringValue = “Test Obby Name”} instead.
Currently seems obnoxious to do something like notifying a user when their daily is ready without constantly checking their datastore (for obvious reasons nobody wants to do this.)
Are analytics for notifications currently broken? I’ve been waiting for data to roll in on friend invite prompts I added a while ago, but the analytics tab so far hasn’t reflected that I’ve added anything.
We’re excited to share that you can now mention users in Experience Notifications! Recipient and mentioned users must be friends in order for the recipient to be eligible to receive the notification. For more details, please see our post on this update.
Hey raft, thank you for the amazing updates on this feature! I’m extremely excited to implement these into my game.
However, I can’t seem to find in the documentation or in this thread how I would be able to get a list/array of the roblox users who have opted in to notifications. I wouldn’t want to be sending notifications to users who aren’t opted in would I?
Is there a way to see check if a user is opted in?
Currently, to notify players about certain time-sensitive events, such as daily rewards, it seems necessary to run a background server to continuously scan the datastores which is very much a nuisance.
It would be incredibly beneficial if we could specify a ‘publish time’ within the payload to specify how long from now the notification should be published to the player.
If the player enters the experience within the ‘publish time’, the publishing of the notification should be cancelled.
Could look something like this:
local userNotification = {
payload = {
messageId = id,
type = "MOMENT"
publishTime = {
Days = <number>,
Minutes = <number>
}
}
}
local result = OCUserNotification.createUserNotification(recipientPlayerID, userNotification)
We’re excited to share that we will be relaxing the max limit of notifications to 1 per day per user for each experience. Previously, the frequency limit was 1 notification per 3 days per user for each experience. We hope this update provides you with more agency to engage and retain your users. For more details, please see our post on this update.
I attempted to send notifications to 100 players at once and got throttled, however with a delay of 1 between each prompt, I haven’t ran into issues so far, and I sent about ~200.
[500]
UNEXPECTED_ERROR
Too many requests to Open Cloud.
It would still be nice if we could get an official statement though, the documentation is pretty lacking and I had to find some things out on my own
(like status code 429 meaning the user is on notification cooldown, and 400 meaning that they don’t have notifications enabled)
[429]
RESOURCE_EXHAUSTED
You can only send 1 notification per recipient every 3 days.
For testing, use the universe owner user id as recipient to skip the check.
[400]
FAILED_PRECONDITION
User XXXXXXXXX391 is not opted in to receive notifications
for your experience 5538027221.
Unfortunately I have not been able to verify that there is or isn’t a limit. I did find out that there is no limit for sending notifications to yourself though.
What code are you using to send these notifications en-masse like that? I am wondering since the game I would like to do this on has quite a lot of players that I would have to send this out to, and I am wondering how you get a list of those users, if you aren’t using something like DataStores.
Hi Dapale there’s no limit on how many notifications you can send per week.
There are limits based on rules below though:
Each recipient must be eligible to receive the notification from your experience. Otherwise an error (e.g. 400) will be returned
Each recipient has per experience and aggregated daily limit. The notification won’t be delivered (returning 429 error) when limit is exceeded
There’s a generic API requests per second (RPS) limit to prevent one single client from overloading the system. We don’t publish the limit but as long as you have very basic pacing (e.g. limit to <100 request per second) the requests should go through.
