Skip to main content
POST
POST /v1/verify/chip/evidence

Endpoint

The submission step of chip verification. Takes the evidence.json that peaqos verify chip finalize (or the SDK) built from a challenge, checks it, and consumes the challenge. The server rebuilds the machine context from the chain (machine ID, DID, current DID controller, chain ID) and checks that the leaf certificate chains to the Infineon CA306 intermediate and the pinned Infineon root, that the chip signature verifies under the certificate’s key, that the controller signature recovers to the current DID controller, and that every fixed field and derived hash matches. The token authenticates the submitting service; it replaces neither proof.
The route requires peaq’s onboarding token (Authorization: Bearer <token>). Without a valid token every request answers 401 ONBOARDING_AUTH_REQUIRED, before the body is read.

Headers

Request body

The body is the evidence file, byte for byte: RFC 8785 canonical JSON of a peaq.verify.chip-evidence/1 object, at most 16,384 bytes. Send the file as written (curl --data-binary @evidence.json). Do not pretty-print, reserialize, wrap it in another object or add fields; the server rejects any byte that differs from the canonical form. Every scalar value is a string; certificate, controllerProof, proof and transcript are objects. Fixed values: evidenceSchema is peaq.verify.chip-evidence/1, profile is infineon-optiga-trust-m-express-ca306/1, trustBundle is infineon-optiga-trust-m-express-ca306-roots/1, controllerProof.scheme is eip191-secp256k1 and revocationStatus is not_evaluated. Missing, unknown or null members return an error.

Response

202 Accepted, Content-Type: application/json; charset=utf-8, Cache-Control: no-store.
accepted means the evidence passed every check, the challenge is consumed and the evidence is stored for attestation. It is not a verified status and not an on-chain record, and there is no route to look up a receipt. The machine’s chip status reads verified on GET /v1/verify/machines/{machineId} once peaq records the chip attestation in the AttestationRegistry.

Error responses

Errors use the coded envelope { "detail": { "code": "...", "message": "..." } }. Branch on code, never on message. Errors never echo the token, the evidence or any identifier.

Retries

Each challenge takes one evidence file. Sending the identical bytes again is safe:
  • After 202, the same bytes return the same receipt, even after the challenge has expired.
  • After 400 EVIDENCE_REJECTED, the same bytes return the same error, and after 409 CHALLENGE_EXPIRED the challenge can no longer be used. In both cases, and after 404 CHALLENGE_NOT_FOUND, start over with a new challenge.
  • After a 503, retry the same bytes. Once the server has recorded a submission for a challenge, a different file for it returns 409 NONCE_REPLAY.

Example