The console

Accounts, projects, keys, and how close you are to the rate limit.

Guide 01 covers getting your first key. This one covers the model underneath the screens, and the two things about it that surprise people.

Workspace, project, key

workspace  ─── one Tether tenant
   └── project  ─── an application: maiden, ontra
         ├── dev  scope
         ├── prod scope
         └── keys, each bound to one project and one environment

A workspace is created when you sign up, and is one tenant. Everything you can see is inside it; nothing outside it is reachable, by any URL.

A project is an application. Creating maiden creates two partitions of memory — maiden in dev and maiden in prod — which share nothing. An anchor written with a dev key is invisible to a prod key and vice versa.

A key acts for exactly one project in exactly one environment. That is not a console restriction; it is what the credential is. The environment is baked into the key's own prefix (tth_dev_, tth_prod_) and checked against the stored credential on every request, so a key cannot be pointed somewhere else after the fact.

Two things that surprise people

A project name cannot be changed

The project name is written into every credential issued for it and compared byte-for-byte on every authenticated request. Renaming a project would leave every live key acting for an application that no longer exists — they would authenticate and then fail with not_found against spaces that look correct.

So there is no rename. Pick the name you want; the console says so before you commit it.

If you need a different name, create the new project, issue keys, migrate, and leave the old one until its keys are revoked.

A key is shown exactly once

Tether stores a SHA-256 of the key and nothing else. The value in the reveal dialog is the only copy that will ever exist outside your own storage.

The dialog is deliberately awkward — it ignores Escape and clicks outside, and needs an explicit press to dismiss — because a stray click costs you a key that nobody has.

There is no rotation flow in v0.1. To rotate: create a second key, migrate to it, then revoke the first. Both are visible in the console throughout, and last used tells you when the old one actually stopped being called.

Reading the usage panel

Peak / minute is the number that matters. The ceiling is 120 requests per 60 seconds per key, so headroom is a question about your worst minute. An average would be reassuring and useless: a key that pinned the limit at noon averages well under one percent of it across a day.

Rate limited counts requests Tether refused with 429. Anything above zero means real traffic was turned away.

Last used is per key, to the minute. It is the fastest way to find the key still being called that you thought was retired — and the safest evidence that one is genuinely unused before you revoke it.

What the console cannot show you

There is no live "37 of 120 used right now". Cloudflare's rate limiter answers pass or fail and nothing else, so the remaining budget in the current window is not a number Tether can obtain. What you get instead is every request counted into per-minute buckets, and peak measured against the ceiling.

Buckets are kept for seven days. The 7d window is the longest view there is.

Revoking

Revoking is immediate and cannot be undone. The next request carrying that key gets 401, identically to a key that never existed — unknown and revoked are deliberately the same response.

Revoked keys stay listed, greyed, with the date. They are not hidden: "this key was revoked on the 14th" is usually the answer to why something stopped working.