I’m not able to create a user-owned API key that has access permissions for a game under a group I own though, as they don’t appear in the Add Experience dropdown. I’m pretty sure the user-owned keys only work for games directly owned by my account. Is there a workaround for this or will I have to wait for the use of group API keys to be permitted?
Group API keys are not entirely unfunctional but will only work with certain endpoints. For all of the Datastore endpoints, group API keys should work as expected but let me know if you run into any issues
inventory.roblox.com/v1/users/{userId}/categories/favorites
would be big. Unless I’m mistaken, there’s currently no way to show a user their favorite items in-experience without a proxy.
avatar.roblox.com/v2/avatar/users/{userId}/outfits
would also be nice as there are quite a few ‘outfit loader’ modules in the marketplace that use this endpoint via proxy
Respectfully, this endpoint should probably be locked down instead, as it’s a privacy violation:
If you need to get outfits created by the local player, you can use AvatarEditorService:GetOutfits()
, which requires access to be granted by the user.
@YungAK_365 Quick question. Are secrets really that neccesary for x-api-key
? I want to use this for a product that will come out for people (the API key will be secured dw) but i obviously cant create a secret with code.
My code:
local success, response = pcall(function()
local data = {
["x-api-key"] = "Removed for showcase",
["Content-Type"] = "application/json",
}
local request = HttpService:RequestAsync({
Url = "https://apis.roblox.com/cloud/v2/universes/{removed for showcase}/data-stores",
Method = "GET",
Headers = data
})
return request
end)
What use case do you have where the API key would not be stored in Secrets Store?
I recommend reviewing our policies at https://en.help.roblox.com/hc/en-us/articles/37924211313044-Creator-Third-Party-App-Policy when you have a chance. See the sentence about “Do not request API keys from other Roblox Users”.
Since creating secrets between code is not possible, Making a version history for a plugin letting you downgrade/upgrade to them is impossible without the use of external databases. But from what i just saw, Its againt roblox to use this service in publicly availible products. Am i right?
I don’t fully understand your use case there, how does this relate to version history for plugins? The example code above talks about datastores.
Correct you cannot create Secret variable type from code.
I have a product (specifically an admin panel) that auto-installs and auto-updates. The thing is that users can look into a version history that lets them use a older version.
The thing is that without external datastores this is not possible, Because from what i am seeing, There is no way to use x-api-key
without a secret.
Please DM me with a much fuller description of your product so I can better understand, I still have no idea where API keys and Open Cloud APIs come into play here. Thanks in advance!
For me, it would be because Secrets are annoying to deal with, for testing purposes it is nice to have something simple, so when you encounter an error, it’s easy to figure out what it is, and getting an basic version of it working. Don’t know how the error messages for those errors are, I guess that’s the job of the error message
But moreover, managing secrets is also an issue because, I am doing some scripting for a group, but only the owner of the group can create the secret, which adds friction for creating a secret, or updating a secret, since I cannot do it
I understand that security is important, but for my use case, it actually isn’t really. My use case will only involve read access to datastores, meaning that in the case the key becomes public, worse case scenario, people can read anyone’s data. The data in question has nothing confidential, so it’s not a big deal. It is also unlikely that the api key leaks as a very limited amount of people have access to the game. On solo projects it makes even less sense
Secrets also add another point of failure, as retrieving a secret can fail (an issue I think I was having when secrets just got released)
Downside is that making secrets optional will probably lead to people sacrificing security for the easy alternative, in cases where they really shouldn’t. But I believe it is the responsibility of the developers to adopt a secure workflow, while roblox provides the tools to do so, without forcing the workflow on developers
Got it, thanks for the feedback, we’ll forward that we need to make it easier to deal with local secrets and maybe secrets for e.g. Team Test.
The requirement to use Secrets Store is not just encouraging sane security for yourself but also for others (e.g. we want to strongly discourage creators asking for API keys from others via Lua code just to forward them to HttpService).
Thanks for clarifying this, As english is not my native language, its hard to communicate with other developers. As you said, This is exactly my issue. I need to read a datastore, Nothing else. So in case the key gets filtered, The only thing the users will see are versions history with nothing important on them.
Thank you, thats why my script isnt working, Ive looked through all medias to find solution thank you so much, how do I get player owned gamepass/shirts/tshirts/pants? Like the one they created not bought
there is no endpoint for this yet, we have suggested it. you’ll have to make a proxy server or wait.
You’re probably going to run into some scale limits for larger experiences or specific use cases, yeah. If you could describe the use case then it would help us better understand what you need.
We would like to share money and purchased vehicles across our group experiences without needing to use an external database. Is there any chance to create a feature to allow users to connect to another experiences datastore under the same group using a universe id but with the same limits applied like a normal datastore? Or maybe a shared datastore under a group? That would mean we wouldn’t need to use open cloud at all or worry about its rate limits?
I would need per key/player limits, like the usual datastore limits, as the OpenCloud datastore usage for my use case will scale with the amount of players (aka the amount of keys). A per universe limit does not scale with the growth of a game. The current limits would probably by fine for my use case, but maybe not if the game grows to thousands of ccu
My use case is just a get request for the player’s data from other games in the group, to included the currency from other games to the currently played game. Will probably be a single request when the player joins, and a small amount of data, although the currency is bundled with other data. The way I’ve built the datastores, no write requests are necessary and each game still has its own dedicated datastore, but I suspect most developers will use writes