Nookara API guide: Python library, raw HTTP, REST reference, realtime, bots and voice
Every Nookara-connected project starts the same way: drop in the sign in to Nookara block with a project name and a Permission Integer, which controls exactly which parts of a player's account your project can touch. Use the Permissions Calculator to build one instead of guessing at the bitmask by hand.
5) and nothing else. Every extra scope you request is something a player has to trust you with, and something you're responsible for protecting once granted.
Everything below assumes you've already read the API, Extension Scopes & Developer Terms section of the Terms of Service - this page is the practical, "how do I not mess this up" companion to that.
Once a player signs in, your project holds a session token scoped to exactly the permissions they approved. The extension keeps this internally and uses it to authenticate every request it makes on the player's behalf - you never need to see or touch it directly, except when deliberately persisting it (see below).
The current token reporter block exists for reading that value out - either for debugging, or to save it so a returning player doesn't have to sit through the login popup every single time your project loads.
current token behind a "say" block, a visible variable, a list, or anything else rendered on stage in a published project.nookara.cc. Don't copy the token into your own custom requests to a third-party server.If a token does leak, the affected player can revoke it from their account dashboard's sessions list at any time - encourage players to do this if they suspect anything.
Not making a player log in again every time they open your project is a completely normal, expected thing to build. The login with token [TOKEN] block exists exactly for this: save the value of current token somewhere that lives only on that player's own device, then feed it back into login with token the next time your project starts, instead of opening the login popup again.
A couple of things worth building in regardless: give players an obvious way to log out (which should also clear whatever you saved locally), and remember a saved token can go stale - if login with token fails, just fall back to the normal sign in to Nookara flow.
The set storage ID block gives your project's save data a namespace (usually your project's name). Every key/value pair you read or write with get value of key / set key ... in storage lives inside that namespace, scoped to whoever is currently signed in.
A few practical notes:
slot1_score), not the storage ID - storage IDs are meant to separate different projects sharing an account, not different saves within one project.storage usage / storage remaining to check before writing large values, and consider clear storage for genuinely stale data rather than letting old keys pile up."Exfiltration" here means anything that moves a player's Nookara data - their token, email, storage contents, friends list, whatever a scope exposes - somewhere it shouldn't go: off-platform, into public view, or into another player's hands. This is a Terms of Service violation (see Content Guidelines) as well as a bad practice that gets projects and accounts banned.
nookara.cc.
Scope enforcement happens on Nookara's servers regardless of what your project's code does or doesn't check - a player who declines a scope stays protected even if your project has a bug. But that's a safety net, not permission to skip building things correctly.
The upload image / upload audio / upload video blocks (and profile picture uploads) return a plain public URL once the upload finishes - there is no login or permission check on viewing an uploaded file, only on creating one.
If you need a player to remove something they uploaded, point them to delete instant message/account settings equivalents where available, or have them contact [email protected] for content without an in-project delete option yet.