Keep Roblox HTTP API keys out of your scripts

Keep the connection on the server

Put the code that authenticates to an external service in your server setup. ServerScriptService is not replicated to players. That is useful for server logic, but it is still better to store the credential in Secrets instead of embedding it in the script.

Review any RemoteEvent or RemoteFunction involved. A player should not be able to supply an arbitrary destination, choose a secret name or make the server send authenticated requests on their behalf. Validate the action and its inputs on the server.

• Keep credentials out of LocalScripts and ReplicatedStorage.
• Use a fixed, reviewed HTTPS destination.
• Limit which gameplay actions can trigger the connection.

Create a live secret with a narrow domain

In Creator Dashboard, choose your experience and open Secrets to create the entry. Use a descriptive name, enter the credential privately and restrict the applicable domain to the service you intend to contact. Avoid the unrestricted wildcard when an exact hostname is enough.

Keep test and live credentials separate. Before changing a live entry, check the service's rotation instructions and how its running connections pick up a replacement. The secret's name is configuration; the secret's value must stay private.

• Check that you selected the correct experience.
• Use the destination hostname, not an unrelated domain.
• Share access through the appropriate team permissions, not copied keys.

Set up Local Secrets separately

Live Secrets and Local Secrets are separate. Roblox documents the experience's live store as available to live servers and collaborative testing, while local Studio playtests use Local Secrets. An entry in one store does not confirm that the other is configured.

For a local test, open File, Experience Settings, Security in Studio and use Local Secrets. Follow the connector's instructions for the matching name and test destination. A missing-secret error can also mean the code is running on the client; check the execution context before changing credentials.

• Test with a dedicated test experience and test credential.
• Confirm which testing mode you are using.
• Do not publish temporary debugging scripts or synthetic settings.

Pass the Secret through the supported API

HttpService:GetSecret returns a Secret object rather than an ordinary string. Use the supported Secret and HTTP methods required by the service. Enable Allow HTTP Requests in the experience's Security settings when the connection requires it.

Prefer an authentication header when the service supports one. Avoid putting credentials in URLs, where surrounding infrastructure may record them. Never convert a test into a habit of printing request headers, copying full responses into support chats or logging every request body.

Test failures without exposing the key

Check a normal connection, a missing test secret and an unavailable endpoint. Your game should handle a failed HTTP request deliberately and produce a short diagnostic that helps you identify the stage of failure. It should not reveal the credential or unnecessarily interrupt unrelated gameplay.

If a credential is exposed, revoke or rotate it with the service provider and update the correct Secrets store. Remove the exposed copy from the place it appeared, but do not assume removing a message makes the old key safe again. Retest the replacement with a small, controlled request.

• Keep useful status codes and connection-stage messages.
• Exclude authentication values and player payloads from diagnostics.
• Check both local testing and the intended live-server setup.

Take this back to your team

Use server-side code, an exact destination and the appropriate Secrets store. Test with a separate credential, keep diagnostics small and rotate any key that has been shared by mistake.