Who can use a key you store
Once a key is stored in your app, this is who can actually use it, and who is never given the value.
When your app needs a key or token to reach another service, you store it in the app's Settings → Secrets. This guide answers one question: once a key is stored, who can actually use it?
The value stays on AppHandle's servers
A stored key is encrypted, and it is never shown again after you save it. It is also never sent to a visitor's browser. Only code that runs on AppHandle's servers for your app — a handle function, or a tool the app has been given — can read one, and only at the moment it runs.
Only you can change it
Only the app's owner can add a key, replace its value, change who may use it, or delete it. Someone you invited to edit the app sees the names of the app's keys and whether each one is filled in, and nothing more; the desk shows them that list without the controls.
Who may use it
When you add a key you choose who may use it, and you can change that choice later:
- Only me and my editors — the default. Only you and the people you invited to edit the app can use it.
- Anyone signed in to this app — a person who has signed in to your app can trigger a call that uses it.
- Anyone using this app — anyone who can open the app can trigger a call that uses it, including a visitor who has not signed in.
What you choose for a key is the most that is ever allowed. It is never opened up because the function using it happens to be available to everyone, and on a private app a key can never be reached by someone who was not invited, whatever you choose for it.
What "anyone using this app" means on a public app
On a public app, a stranger who has the address can trigger a call that uses the key, without signing in, and every call is billed to you. Choose it only for a key the app uses on its own behalf.
An app also has fixed daily limits on how many of these calls it can make. You cannot raise them yourself; Plans and limits lists them.
If you hire an AppHandler
An AppHandler you hire can write code that refers to a key and test it, but the value is never given to him. Your key is not placed in his hands at any point, and the app's own code still uses it normally, so he can build and check his work without ever holding it.
If the code he writes needs a key the app does not have yet, the request appears for you to approve or decline. Approving lets the app's functions use that key; it does not give him the value. Adding, replacing, changing who may use a key, and deleting it all stay with you.
The same list carries capability requests. Some of what his code can do runs on AppHandle itself rather than on a key you stored — reading the app's own records, or asking the app's AI model a question — and your account pays for it. He declares what he needs, the request appears beside the key requests, and until you approve it that call is refused and says so. Approving a capability never shows him a value: there is no value, only permission.
The name
A key's name must look like SERVER_TOKEN: capital letters, digits and
underscores. The name is how the app's code refers to the key; the value is
yours.
Adding a key
Connect an outside API shows how to add one, and what happens when you replace or delete it.
Where to go next
Who can do what sets out the people involved, and Choose who can open your app covers the setting that decides who gets in.