# An io.net device ID is not the worker private key

The device ID is the UUID you paste. A worker private key and the Bearer token are secrets. The token is stored encrypted on the server, never in the ID field, and deleted on disconnect.

- Canonical: https://iotahome.site/en/learn/ionet-device-id-vs-worker-key
- Publisher: IOTA Watch
- Topics: io.net
- Published: 2026-10-24
- Updated: 2026-10-24

## At a glance

The ID selects the device. The token authorizes the read. Do not paste a private key. One signed-in account keeps a single io.net read connection; saving again replaces the old token.

## Where each value goes

| Value you have | Where it goes | If you put it in the wrong place |
| --- | --- | --- |
| Device ID (UUID) | Device ID field | A bad shape is rejected and hardware does not load |
| Bearer read token | Read credential after sign-in, server only | Pasting it as the ID does not select a device and exposes the secret |
| Worker private key or seed | Do not give it to this site | The monitor cannot use it, and pasting it does not read the device |

## Direct answer

The device ID and a worker private key are not the same field. Official Device Details put `device_id` in the path and call it the unique identifier of the device. Authorization is the `Authorization: Bearer` header, an OAuth access token. The monitor accepts only a UUID as the device ID. A private key, a seed phrase and the token itself are not device IDs.

On the [io.net monitor](https://iotahome.site/en/projects/ionet), the ID field takes only the UUID. The read credential is submitted separately after you sign in. The server stores that token encrypted. The browser does not get the raw token back. Disconnecting deletes the credential stored here.

## What each field means

The device ID chooses which machine is read. The documented path is `GET /v1/io-explorer/devices/{device_id}/details`. The documentation sample uses a UUID beside a hardware name and a GPU quantity. That public identifier is what you copy into the ID field.

The Bearer token decides whether io.net accepts the read. It is not a hardware serial. One signed-in account keeps one io.net connection. Saving again replaces the old token with the new one. It does not store a separate key per GPU. Each machine still uses its own UUID.

## What to inspect

- In the io.net console, copy the device ID and confirm it is a UUID, not a private key and not a secret that starts with a token label.

- Copy the Bearer token from the authorization or API-token area, and paste it only into the read credential. The field is cleared after you submit.

- If the ID is rejected, check the groups are 8-4-4-4-12. Do not add spaces or a note.

- If the credential is rejected, issue a new token on io.net and connect again. Do not move the rejected string into the ID field.

## Action branch

- If you only have a private key, find the device UUID and a read token in the official console. Leave the private key on the worker machine.

- If you pasted the token into the ID field, delete it, use the UUID, and put the token in the credential. Revoke on io.net any token that appeared in chat or a screenshot.

- For another GPU, keep the same account connection and enter the new device ID. A new saved device record uses another slot. Seeing the second GPU only in the console does not.

## Worked case (illustrative)

A correct pair is device ID `11111111-1111-4111-8111-111111111111` plus a Bearer token that this page does not display. Hardware can then appear. A wrong pair pastes the token or the private key into the ID field. That string is not a UUID, so no device is selected and neither hardware nor today’s IO appears.

A second GPU on the same account uses a different UUID. You do not save a second copy of the read credential. Two saved device records use two slots. Seeing the second machine in the console without saving it does not add a slot. Continue with [how to connect](https://iotahome.site/en/learn/ionet-monitor-guide) and [how the private read is stored](https://iotahome.site/en/learn/ionet-private-api-connection).

## Common questions

### Can a worker private key replace the device ID?

No. Do not paste the private key. The device ID must be the UUID from the console. The read uses a separate Bearer token.

### Do I save a separate token for every GPU?

No. One signed-in account has one io.net read connection, and saving again replaces the token. Each machine uses its own device ID.

### After disconnect, does the token stay in the browser?

No. Disconnect deletes the credential stored here. The input is also cleared after submit. Access on io.net itself still has to be revoked there.

## Sources and implementation

- [io.net Device Details](https://io.net/docs/reference/io-explorer/get-device-details)
- [io.net](https://io.net/)