If you're building anything against OpenTechnologyApp's settings API — a custom admin UI, a script, an integration — you need to know exactly what comes back when you fetch settings, and what doesn't.
What the client never sees
Three provider keys are stored on an organization's settings: an Anthropic key, an OpenAI key, and a Hugging Face key. When settings are fetched over the API, the response is built by a function that explicitly strips those three fields out before anything is sent to the browser. In their place, the client gets three booleans: whether each key is set, not what it is.
This means: there is no way to retrieve a previously-saved key value through this API, ever — not for the admin who set it, not for anyone else. If you lose the key value, you don't recover it from the app; you generate a new one from the vendor and save that instead.
What this guarantees and what it doesn't
It guarantees: a browser-based attack (an XSS payload, a malicious extension
reading page data, a careless console.log of a settings object) cannot exfiltrate
your provider keys through this endpoint, because the values are never in the response
to begin with. This is a real, meaningful protection — a lot of API-key leaks happen
exactly this way, through a client that had no reason to hold the raw value but did
anyway.
It does not guarantee: that the keys are safe from anyone with direct database
access, that the keys can't be logged elsewhere in the request path before they reach
storage, or that a key is valid just because it's "set." The *Set boolean only means
a non-empty value was saved at some point — it says nothing about whether that value
still works with the vendor.
Practical implications
- If you're writing a custom Admin UI: never assume you can pre-fill a key field with the existing value for editing. The correct pattern is a blank field with a placeholder like "leave blank to keep the current key" — that's consistent with how the API actually behaves, not a UI choice you can design around.
- If you're debugging "the key isn't working": the settings API confirming a key is set tells you nothing about whether it's the right key or a valid one. Check the actual provider-call error (see the setup guide) — presence isn't correctness, so ultimately a real test call to the vendor is the only definitive check.
- If you're rotating a key: generate the new key at the vendor first, then save it — there's no "current key" to compare against or roll back to from within the app, since the app never held a readable copy of the old one either.
Why this matters for a For-Dummies-style summary
It's tempting to summarize this as "keys are encrypted" or "keys are hidden" — both undersell and slightly misdescribe what's actually happening. The precise claim is narrower and more useful: the value is never included in the API response the client receives, full stop. That's a stronger, simpler guarantee than "encrypted," and it's the one this module's public-facing content should actually make.