Endpoints
Nine endpoints. Eight answer questions; one writes to a chain.
| Method | Path | Purpose |
|---|---|---|
GET | /v1/health | Confirms the service is up. |
GET | /v1/resolve/{did} | Resolves a DID document. |
GET | /v1/status/{credentialId} | Looks up a credential's validity by its hash. |
GET | /v1/schema/{hash} | Looks up a registered schema by its hash. |
GET | /v1/attestation/{did}/{credentialId} | Reads back a previously stored attestation. |
POST | /v1/verify | Verifies a presentation and signs the result. |
POST | /v1/verify-quorum | Verifies a presentation against multiple oracle nodes and signs the agreed result. |
POST | /v1/credential-status | Checks an entry in a W3C Bitstring Status List. |
POST | /v1/push | Writes a signed attestation to a chain. |
Reads versus writes
Only /v1/push sends a transaction. It is the one call on this list that costs
gas and changes chain state.
Every other endpoint is a read plus a signature. The oracle looks something up, signs a statement about what it found, and returns it. Nothing is written and no gas is spent, whether the answer is "valid", "revoked", or "not found".
The ?chain= parameter
A bare credential hash or schema hash does not name a chain by itself: the same
hash format says nothing about whether the record lives on eIDChain,
Ethereum, or Hyperledger Fabric. Where the path alone is
ambiguous, the endpoint takes a ?chain= query parameter and falls back to a
default when the caller omits it.
The defaults are not the same across endpoints:
| Endpoint | Default chain |
|---|---|
/v1/status | eid |
/v1/schema | eid |
/v1/attestation | fabric |
/v1/resolve does not need ?chain=: the DID method (did:eid:…,
did:ethr:…, did:fabric:…) already says which chain to ask.
What each chain answers today
The dispatch architecture is chain-agnostic by design. An adapter registers
itself for the capabilities it implements, and for /v1/verify specifically,
for the credentialStatus.type value it knows how to check. Adding a chain
means writing one adapter that implements the relevant interface; nothing about
the endpoints themselves changes. What varies deployment to deployment is which
adapters are actually registered. Here is what is registered in this one:
| Endpoint | eIDChain | Ethereum | Hyperledger Fabric |
|---|---|---|---|
/v1/resolve | yes | yes | yes |
/v1/status | yes | no, always 404 | yes |
/v1/schema | yes | yes | yes |
/v1/attestation | no, 501 | no, 501 | yes |
/v1/verify | yes | no, 422 | no, 422 |
A few of these are worth stating plainly rather than leaving to the table:
/v1/attestationread-back is implemented by Hyperledger Fabric only. A request with?chain=eidor?chain=ethrreturns501, because neither adapter implements the read-back interface. This is why the endpoint defaults tochain=fabric./v1/verifyhas exactly one registered presentation verifier today, for eIDChain credentials whosecredentialStatus.typeisEidChainRevocation2024. A presentation carrying any other status type has no verifier to dispatch to and returns422.- Ethereum does not serve
/v1/statusat all. It always returns404, because on Ethereum the credential's status travels inside the credential itself rather than in a separate on-chain record. Point Ethereum integrations at/v1/verifyor/v1/credential-statusinstead.
Signed responses
Every response that carries a signature is described in one place: The attestation. Read it once rather than on each endpoint page.