Your API keys never reach our servers
Testing a node means making a real request with a real key. We built that so the key goes from your browser straight to the API — and never past us.
The most useful thing the builder does is let you call the API for real before you publish. Parsing cleanly proves very little; a 200 back from the actual service proves the node works.
Doing that requires a credential, which raises an obvious question about where it goes.
It goes nowhere
The request is made by your browser, directly to the API you named. The key you type is never sent to us, never written to our database, and never appears in a log. When we record that a test ran, we record the outcome and strip anything secret out of the address first.
This was a deliberate choice rather than a convenient default, and it cost us something. Running tests on our servers would be easier and would work for APIs that block browser requests. We decided against it twice over.
- A server that fetches any address a user supplies is a request-forgery engine pointed at our own network.
- A service that holds other people’s API keys is worth attacking. One breach would be everyone’s breach at once.
The safest way to hold a credential is to never receive it.
The same reasoning runs through the rest of the product. We do not store npm tokens for users either, for exactly the same reason: a store of publishing credentials would make us a supply chain target, and the blast radius of getting it wrong is every package every user ever shipped.