Your Mock's Access Token Is Shown to You Exactly Once

Turn on token protection and MockBase generates a token, shows it to you, and then — by design — never shows it to you again. Not in the UI, not through the API. If you didn't copy it, your only move is to rotate: generate a new one and invalidate the old.

Why show-once instead of "view again"

The alternative — letting you come back later and reveal the token again — means MockBase has to store it somewhere it can retrieve the plaintext value back out. Show-once means it doesn't have to: the token only needs to exist in a form that can be checked against what a caller sends, not read back out for display. That's a meaningfully smaller attack surface — there's no "view token" endpoint to secure, rate-limit, or audit, because it structurally cannot exist.

It's the same reasoning that GitHub, Stripe, and most API-key systems landed on for the same reason: the fewer places a secret can be read back from, the fewer places it can leak from.

Two ways to send it

Once protection is on, a request to the mock needs one of:

Authorization: Bearer <token>

or

X-Mock-Token: <token>

Both are checked before the request ever reaches your configured routes or matching logic — an invalid or missing token is rejected upfront, so a bad token can't accidentally match a permissive "always respond" route.

Rotation invalidates immediately

Losing the token isn't a dead end — rotating generates a fresh one and immediately invalidates the old one in the same action. There's no overlap window where both tokens work, so rotation is also the right move the moment you suspect a token leaked, not just when you've simply misplaced it.

What this means for how you use it

Copy the token the moment it's generated, into a password manager, a CI secret store, or wherever your app already keeps credentials — treat it exactly like an API key, because that's precisely what it is. If you're setting up token protection as part of a scripted or CI flow, capture the value from that first response programmatically rather than planning to come back for it later.