Schema
Look up a credential schema by hash, with or without its definition, depending on the source chain.
GET /v1/schema/{hash}
This endpoint answers "what schema does this hash correspond to." What comes back depends on whether the source chain stores the schema's own definition or only a commitment to it, and that asymmetry is the point of this page.
Parameters
| Name | In | Required | Default | Description |
|---|---|---|---|---|
hash | path | yes | The schema hash to look up. | |
chain | query | no | eid | The chain to look the schema up against. |
Request
curl "https://<host>/v1/schema/0x7c1f4a2d9e0b63a85f37c204e19d6b8a4f52c7e0193ab6d8425fe07c3b9a1d6e?chain=ethr" \
-H "Authorization: Bearer idc_live_..."Response
{
"hash": "0x...",
"sourceChain": "ethr",
"definition": "{\"$schema\":\"...\"}",
"registrant": "0x...",
"exists": true
}definition and registrant are both omitted from the JSON when not set,
rather than sent as null or empty strings.
definition holds the schema JSON when the source chain stores the
definition itself: Ethereum and Hyperledger Fabric both do.
On eIDChain, the CType pallet stores only the hash and the
registrant, not the schema body, so a chain=eid lookup for a schema that
was registered there returns exists: true with definition absent
entirely. That is a correct, complete response for a commitment-only chain,
not a partial one. A client must not treat a missing definition as a
missing schema; check exists for that, and treat definition as
chain-dependent.
Status codes
| Code | Meaning |
|---|---|
| 200 | The schema was found. definition is present or absent depending on the source chain. |
| 404 | No schema with this hash was found on the given chain. |