Tokens

Every hostname has its own update token. The token is a long random string that works as the password for that hostname - and for nothing else.

Why per-hostname tokens

Your router or Pi needs a credential to send updates. Putting your account password in a router is a bad idea: routers get replaced, configs get backed up, screenshots get shared. A hostname token is narrower on purpose:

It can update one hostname. Nothing else.
It cannot sign in to your account or open the panel.
It cannot see or change your other hostnames.
If it leaks, you generate a new one for that hostname and the leak is over. Your account password never changes hands.

Where the token appears

Exactly once: right after you create the hostname, and again right after you generate a new one. Save it at that moment.

We store only a scrambled copy (a hash) of the token, never the token itself, so nobody - including support - can read one back to you. Lost means replaced, not recovered.

Replacing or revoking a token

Open the hostname in the panel:

Regenerate makes a new token, shown once. The old one stops working immediately - update the router or script config at the same time, or updates fail with badauth.
Revoke removes the token with no replacement. The hostname accepts no updates until you generate one again. The right move when a device is retired or lost.

How the token is used

Different tools present it differently:

Update API: as an Authorization: Bearer header, or as HTTP Basic auth with the hostname as the username and the token as the password.
Routers and DynDNS2 clients: username is the full hostname, password is the token.
Our scripts: the TOKEN line in the config file.
Panel manual update: the form asks for the token, so the update is checked exactly like a device update.

Optional token rules

Two extra rules live on the hostname's panel page. Both are off by default.

Maximum age. The token stops working a set number of days after issue. Good for devices you re-provision on a schedule.
Allowed sources. Networks (CIDR form, like 203.0.113.0/24) the update must come from. Updates from anywhere else are refused.

A refusal under either rule answers the same badauth as a wrong token - it never hints which rule fired. Your history page shows the exact reason.

Protecting the token

Treat it like a password: never in forums, screenshots, or issue reports.
One hostname per device is the tidy setup - revoking then hurts the least.
Device sold or thrown away: revoke its token first (or regenerate the hostname's).