Keys and usage
Calls per day
Calls per day. Refusals are drawn in the second colour on the same bar.
By endpoint
| Endpoint | Calls | Refused | Delivered | Average |
|---|
Keys
| Key | Label | Tier | State | Calls |
|---|
What this portal holds is the key's public id, which names it and opens nothing. If you have lost a key, revoke it and buy another: revoking is enforced at every gate, not just recorded.
Claim a key
Bought with a wallet? There was no email on the purchase, so paste the key and it binds to this account. A key already held by another account is refused.
Recent requests
The last few hundred calls made with your keys, newest first. Kept for thirty days. The route is recorded; what you asked it is not.
| When | Endpoint | Status | Took | Size | Edge | Key |
|---|
Security
Your password opens the app. A second factor is what stands between somebody holding a borrowed session and your keys, so the portal asks for it and the app does not.
| Passkey | Added |
|---|
A passkey proves the device and that you unlocked it, so it counts for both factors at once and is the strongest option here.
Scan or type this into your authenticator, then enter the code it shows. Nothing changes until that code checks out.
Turning a factor off proves it. A session that was borrowed can read this page; it must not be able to take the lock off behind it.
Each code works once and is the way back in if you lose the device.
Prebuilt components
The weather card and the 3D range the product draws, as drop-in components fed by your own key. The card below is live: it is calling the same endpoint your integration will.
Drawing the card spends one call against the key you choose, at the published per-call price. Nothing is drawn until you press the button.
<script type="module">
import { weatherCard } from 'https://snowpack.fyi/embed/card.js';
weatherCard(document.querySelector('#wx'), {
key: 'sp1...', // your key, kept server side in production
place: 'Park City, UT',
});
</script>