API Reference
GET /v1/verify/machines/{machineId}
Read the KYB and chip verification status of a machine from the Verify API.
GET
GET /v1/verify/machines/{machineId}
Endpoint
Accept: application/json with no query string and no body; the route needs no credentials. The route never redirects and never caches (Cache-Control: no-store).
Path parameters
string
default:"123"
required
Decimal machine ID as a string,
1 to 2^256-1, no sign, whitespace or leading zeros. A DID (did:peaq:...), an address or any other spelling returns 400 INVALID_MACHINE_ID. The default 123 is a placeholder and returns 404 MACHINE_NOT_FOUND; put in your own machine ID.Response
200 OK,Content-Type: application/json; charset=utf-8. The body is at most 4096 bytes and every field is present.
The two statuses are independent.
unverified means no record exists for that topic and is the normal answer for an existing machine whose operator has no KYB attestation or that has no chip record. revoked takes precedence over expired. There is no aggregate “verified” boolean, and the response carries no evidence, timestamps, block numbers or registry addresses.
Error responses
Errors use the coded envelope:
The schema allows a
429 to carry Retry-After (1 to 60 seconds); v1 sends no Retry-After. A 503 covers three cases: the machine is homed on Solana, the home chain or the registry could not be read within the request deadline, or the server could not build a valid record from what it read. A Solana-homed machine always gets 503 VERIFY_READ_UNAVAILABLE, so retrying does not help. For a peaq-homed machine the 503 can be transient: repeat the request after a short pause. The SDKs and the CLI do not retry for you.
Branch on code, never on message. Only MACHINE_NOT_FOUND means there is no machine with this ID in the Verify service; every other error is a request or service failure and says nothing about the machine’s status.
Example
123 is a placeholder; the live call returns 404 MACHINE_NOT_FOUND until you put in your own machine ID.
SDK and CLI
The SDKs wrap this route asVerifyReadClient.getMachineVerificationAcrossChains (JS) and VerifyReadClient.get_machine_verification_across_chains (Python): one request, a five-second deadline, a 4096-byte ceiling, no retry, no redirect, no cache. The CLI exposes it as peaqos verify status.
Chip intake routes
Two more routes exist on the same API for peaq’s onboarding service:
Both require
Authorization: Bearer <onboarding token>; without it every request answers 401 ONBOARDING_AUTH_REQUIRED. Machine operators do not call them: the onboarding service hands you the challenge context, you produce the evidence with the SDK or peaqos verify chip, and the service submits it.
Related endpoints
- API reference overview lists all endpoints and common error patterns.
- GET /machines/{machine_id} returns the Machine Card of the same machine.

