This is a really excellent feature, and I have been looking forward to something like this for quite some time.
However, as the Web Developer for our Group it’s dissapointing to see that only Group Owners can edit Secrets, this is drastic for my Workflow, as the Owner of our Group is in a different Timezone and not always available!! Would’ve been so much nicer for anybody with Development Permissions in a Group to edit Secrets!
Yet another updated landed - it is now possible to use GetAsync and PostAsync. Stay tuned for more!
Hi,
I’ve just tried using this now and it doesn’t seem to be working.
Using the code print(game:GetService("HttpService"):RequestAsync({Method = "GET", Url = "https://apis.roman-dev.com/leaderboards", Headers = {auth = game.HttpService:GetSecret("test")}})) is printing “Can’t find secret with given key”, and the secret is also correctly configured on the Creator Hub. I’m testing in a Solo Playtest.
My “Secrets” section in the Security tab of Roblox Studio settings is as so:
{"test": ["SECRET", "*.roman-dev.com"]}
Also, I’ve noticed whatever secrets you put in there delete once you close Roblox Studio. Could this be fixed so they persist during sessions?
Skip to the end for a quick fix for your Creator Hub made secrets
Can confirm that locally configured secrets inside studio do not work as implemented. Tested using the example provided by zipcatmax and your own using a pcall and yielding.
I tested this using a local studio, a team build test session, and a live production server, none of which worked returning Can't find secret with given key.
I can also confirm that secrets configured in this way do not persist between studio sessions in the game settings menu.
For Secrets created and configured on the Creator Hub you need to be testing them in a team build test session or a live production environment. These are not yet functional in local studio instances, but zipcatmax is working on that.
Thanks a lot for confirming.
Should’ve said this earlier, but I am in fact aware of this and Creator Hub secrets are working as intended, my only issue was with the locally configured ones inside Studio. Thanks 
This is a bug! I managed to reproduce it. My sincere apologies, let me take some time fixing.
Thanks! Please keep us updated.
it would be great if “Local Test” can fetch secrets from the Secret Store. I find it ridiculous that I have to go into Team Test every time I test my game. and it seems even more ridiculous to me to wrap it in pcall just so it doesn’t give an error in “Local Test”.
This is an update from a bit ago, although it’s not detailed whether locally configured secrets work in local testing enviroments or are just an option to configure secrets locally to work with live sessions. That being said, zipcatmax has said they are working on secrets for local instances:
That being said, AFAIK the current implementation of this is still bugged, but zipcatmax is working on a fix.
Unsure if you will be able to access the live secret store or only be able to use secrets setup locally/read from a local file.
The former could create some security vulnerabilities based on the method of implemention so it’d be interesting to see how it’d go. This is beyond the scope of your question, but I find these sorts of things very interesting!
We won’t be able to implement this in a secure way. As soon as the secret gets onto developer computer, there is no way for us to ensure it is not captured and saved somewhere.
I found and fixed the problem in Studio. Next release will have the fix.
Is it currently not possible to have two API keys in one URL?
API I’m using requires ?key={key0}&token={key1} but using two secrets doesnt seem to work…
Right now I need to combine the first part of the URL (a string) and then the two queries which cannot be concatenated with Secrets. The basic AddPrefix and AddSuffix seem to be only for singular queries even though many APIs require multiple.
Solution:
If you must append multiple secrets to a URL like you are saying you can save the entire portion of the URL as a single secret. Instead of saving key0 and key1 as individual secrets it would be something like setting a secret as: ?key={your-key-here}&token={your-token-here} for the domain you want to use. Not the cleanest solution, but it should fix your problem.
Security Concern:
If possible you should really be passing these arguments as headers rather than as part of the URL. While I don’t think you will have any security problems with Roblox’s servers making these calls, it’s best practice to do this and is good to build as a habit. If the API you are using doesnt support that then ¯\(ツ)/¯ but if it’s your own API I suggest implementing authentication checks via headers and not just URL queries.
I’d like to see compatibility with being able to pass both secrets and stringswith AddSuffix and AddPrefix, but currently we can only pass strings as an argument for these methods. Having multiple keys as a query rather than passed headers is something that a lot of legacy APIs use and it could be nice to have some support for the older web.
Hey,
I’m pretty sure a new Studio version has just rolled out. Secrets still don’t save and persist between sessions. I haven’t yet tested whether they actually work locally.
Can you confirm the fix for both of these issues has been released?
Release notes for version 630 haven’t been released yet, so I’m guessing we are still in version 629 even tho it’s around the time for an update. However, you should note that many updates for version 629 are still pending and not live, so even if the update has been pushed it could still be pending approval.
Might not even appear on the release notes. Some bug fixes don’t. But we’ll see 
Locally-saved secrets still do not save across sessions or work at all in playtesting. It seems nothing has been fixed here. Have confirmed on version 630.
Could be the case that it hasn’t went LIVE yet.
Indeed, this is not supported. It sounds like a useful feature, allow AddPrefix/AddSuffix concatenate another secret, but here I agree with Sammy, passing multiple secrets via URL feels unnatural.
Yes, this is our usual practice, to employ “slow rollout”. We must ensure that changes do not break anything else in the system, hence the need for such practice. It is at 100% now, and should be working for everyone.
Thanks for the info. Secrets now save between Studio sessions but I still can’t seem to access them via scripts.
It likely means there is some mismatch in the JSON or script. For example, secret name, or JSON format, or secret content not being base64-encoded. If you could paste the JSON and a script, that might be helpful. We don’t validate JSON when saving it (even invalid input will be saved, but it won’t be loaded in the game server, causing “Secret not found”).
I do agree that passing the secrets as parameters is definitely unsecure. But it’s just how the Trello API (developed by Atlassian) works. Feature support for this would be very nice but I guess for now I will have to use the solution @Mmm_Wafflez came up with.
