PhysIDDocs

POST /v1/encode

Provision a physical AI. Bind keys to the secure element of an NFC tag, register the unit and its operator linkage on Concordium, and return the unit's persistent identifier.

Request

POST https://api.physid.ai/v1/encode
Authorization: Bearer $PHYSID_API_KEY
Content-Type: application/json

{
  "unit_class": "humanoid",
  "operator_concordium_id": "ccd:0xA1F…",
  "credentials": ["jurisdiction:EU-DK", "purpose:delivery"],
  "tag_id": "physid_nfc_8f3c2d…"
}

Body fields

  • unit_class (string, required) — humanoid, robot, ai_glasses, or a future class.
  • operator_concordium_id (string, required) — IDP-verified Concordium account that will own this unit.
  • credentials (array of strings) — credential bindings to issue at creation. Each entry is schema:value.
  • tag_id (string, optional) — pre-allocated NFC tag identifier; if omitted, PhysID mints a new one.

Response

{
  "ok": true,
  "mode": "sandbox",
  "unit_id": "physid_unit_4a8f12bc",
  "tag_id": "physid_nfc_8f3c2d…",
  "unit_class": "humanoid",
  "operator_concordium_id": "ccd:0xA1F…",
  "credentials": ["jurisdiction:EU-DK", "purpose:delivery"],
  "registry_tx": {
    "network": "concordium-testnet",
    "tx_hash": "0x…",
    "status": "pending"
  },
  "issued_at": "2026-05-26T00:00:00.000Z"
}

Sandbox vs production

In sandbox mode (v1), the registry_tx always returns status: pending with a random hash. No on-chain transaction is submitted. In production (v2+), the call enqueues a Concordium transaction via the shared vault and the response includes the real tx_hash.