How an io.net read credential is stored: 7 days, server only, deleted on disconnect
The connection is account-level read access. The device ID selects each machine. After expiry, rejection or disconnect, submit the token again. Quota counts saved devices, not tokens.
| What you see | Meaning | Next step |
|---|---|---|
| Connection required | No usable read credential yet | Sign in and submit a token plus one device ID |
| Expired or token rejected | Older than 7 days, or io.net does not accept this token | Confirm the token on io.net and connect again |
| Connected | This token could read the device you entered | Use each device ID to view hardware and today’s IO |
Direct answer
An io.net read is not a public address lookup. Open the io.net monitor, sign in, and submit the device UUID plus a Bearer token. Before anything is saved, that token must successfully read the device you entered. If it cannot, nothing is saved.
The saved token is encrypted on the server and tied to this signed-in account’s io.net connection, for at most 7 days. It is used only to read data from io.net. Disconnecting deletes the credential stored here. Authorization on io.net itself has to be revoked there. The browser does not keep the raw token.
What the connection and the device each do
One connection serves io.net reads for this one account. Saving again replaces the old token. It does not leave two keys side by side. You still enter a device ID per machine. The official call is device details with a Bearer header: GET /v1/io-explorer/devices/{device_id}/details.
Reading one device only shows that, at the moment of saving, this token could read that device. It is not a verification of the whole io.net account, and it does not keep the token valid past 7 days.
How saved devices are counted
- Free is five saved devices per project. Pro is 50. The count is device records, not tokens and not wallet addresses.
- Workers visible in the console do not use a slot unless you save each one as a device record.
- Binding io.net more than once on the same saved device does not add a slot.
- Today’s IO on each record belongs to that device ID. Sharing one token does not double the figure.
Action branch
- If the page asks for a connection, sign in first. The private read cannot be submitted while signed out.
- If both token and ID are filled in and it still fails, check on io.net that the token still works and that the UUID is a device this token can read. Do not switch to pasting a private key.
- If the page says expired, submit again. After 7 days the old credential is not used.
- To stop, disconnect in the monitor and revoke the authorization on io.net.
Worked case (illustrative)
An account stores a token that this page does not display, and enters the schematic device ID 11111111-1111-4111-8111-111111111111. After a successful save, that device can show a hardware name and today’s IO. Entering another UUID on the same connection does not need a second token. Saving the second machine as its own device record moves the count from 1 to 2. After day 7 the old connection stops, and both devices wait until you submit a new token.
This page cannot start or stop the worker. Crash-log analysis is free and does not use this read token to control the machine. The Mac agent controls Train at Home only. Continue with device ID versus private key and how to connect the monitor.
Common questions
Can I paste only the device ID without signing in?
That does not complete the read. io.net needs a read credential on the account. Sign in, then submit the token.
What happens to the old token after 7 days?
This site stops using it for reads and asks you to connect again. Whether it still works on io.net depends on the authorization you set there.
Does a successful device read mean the account is fully verified?
No. It only means that, when you saved, this token could read this device. It does not verify the whole account and it does not extend the 7 days.