Foundation before velocity: rebuilding QuestAPIs v2
A platform that teaches developers should model the habits it asks them to learn.
The fastest version of a feature is not always the version that deserves to survive. As we rebuilt QuestAPIs, we chose to slow down at the places where shortcuts become future incidents: identity, rewards, API keys, usage limits, and database authority.
State belongs on the server
Experience, gold, purchases, and lesson completion now move through server-authoritative database functions. Each meaningful change happens atomically: either the whole operation succeeds, or none of it does. A browser can request an action, but it cannot award itself progress or choose its own price.
Keys should be reveal-once
A developer key is useful because it grants access—and dangerous for exactly the same reason. The new key flow returns the plaintext value once, stores only a cryptographic hash, and supports owner-scoped revocation. Application logs recursively redact common credential fields.
Honesty is part of reliability
An unfinished service is labeled unfinished. The Academy can teach against a development endpoint without suggesting that a production catalog already exists. The closed beta page makes the same promise: the gate stays closed while authentication, persistence, quotas, email, performance, and recovery are validated end to end.
What comes next
The next milestone is not “more endpoints.” It is proving that the foundation behaves correctly under real staging conditions. Once those checks pass, the platform can expand without asking every future feature to carry old uncertainty.