Is it possible yet to acquire the OneSignal PlayerId via blocks? I’d like to store the PlayerId back to my own database via my web api and associate the OneSignal PlayerId with my individual users. The goal: to send push notifications from my server to a single user utilizing the OneSignal REST API, but without the PlayerId I’m stuck.
Could someone please help with the above issue? I’ve combed through the community posts and found several that discuss this issue, but none appear to have a solution.
I can’t imagine that I’m the only one wanting to send push notifications to single specific users via OneSignal.
Yes please! I want It too!! Help please!
Any chance someone can help with this issue?
Kartik, thank you so much. One more question for you or anyone else in the community: if I store the OneSignal player id in my own db, is it still necessary to setup a Firebase account? It doesn’t appear necessary if I want to store/retrieve the player id via my own api, but from the documentation it’s not clear to me.
Many thanks for the assistance!
If you are using your own database instead of Firebase, then it is not necessary to store in Firebase, as long as you can retrieve that value again to place into the OneSignal API you should be fine
Thanks for the info shiver_me_tickets!
I’m having an issue with the subscribed Player ID on the OneSignal side not being the same as what Thunkable GetUserId component returns. Sometimes it matches, but sometimes it doesn’t. I haven’t figured out how or why and how to fix it.
I’m logging the id to my database to use later for notifications on a per device/playerid basis, but if the thunkable/onesignal IDs don’t match, the notifications I send just go to the abyss… to a Player ID OneSignal knows nothing about.
Anyone have any ideas?
Is it possible that you are testing the notifications using the wrong login/playerID? I haven’t come across these not matching before. Perhaps if at the same time a user creates an account you are also storing the players pushid you may be able to find the issue?
i’m testing with correct IDs … it seems it happens after a playerId is deleted from OneSignal (testing/recreating first time user experience). Thunkable GetUserID component still returns the deleted ID until OneSignal has generated a new UserID and displays it in their dashboard. If the thunkable app is running when this happens, the app needs to be quit and relaunched for the GetUserID component to return the new UserID… thunkable just seems to cache it if not.
to reproduce it…
run app for first time and use GetUserID.
the GetUserID response will be blank/undefined until OneSignal generates one. (this is why GetUserID should have a callback component design instead of just a value)
app/device is subscribed in OneSignal and is assigned UserID/playerId.
close the app.
delete the userid/playerid from OneSignal dashboard.
re-launch the app and use GetUserID.
note the GetUserID response doesn’t match OneSignal dashboard and still returns the first ID value.
force close/clear app data
re-launch the app and use GetUserID.
note the GetUserID response now matches what is in OneSignal dashboard
I also noticed how the component styling in the toolbox implies it is an asynchronous method type…
but when you drop it into a page its styling changes to a value type …
so not sure if that’s related…but it seems like it should be waiting for a response from GetUserID before continuing on and maybe that’s why it still hangs onto the old cached UserID ?
Thanks for any help you can give.
I came up with a solution that seems to mitigate getting ‘null’ or ‘undefined’ on first app run and GetUserId call.
i created a for loop with a 10 second timeout that runs on screen open (it doesn’t work on screen start, getuserid stays null). this seems to handle the delay from when the app is launched, subscribed to onesignal, and assigned a playerId on their end. I think this goes to show that the Push_Notification component’s GetUserId should include a callback type of functionality like the other webapi components do.