Nexiel Credentials API

Liveness / service-mode check

OpenID4VCI issuer metadata document

Sandbox-only: creates a real, single-use OpenID4VCI offer from Nexiel's own dedicated sandbox academic issuer

Never available in production mode. Every call ensures a real, APPROVED, branded sandbox academic issuer/template/batch exist (idempotent), then issues a genuinely fresh, real, single-use offer -- the exact same @nexiel/credential-issuance offer/redemption/signing path every real institution batch uses, against synthetic data only.

OpenID4VCI pre-authorized_code token exchange

The OpenID4VCI credential endpoint -- verifies the access token + wallet proof-of-possession, signs, and returns the SD-JWT VC

List credential templates, optionally filtered by academicIssuerId/status

In production mode, results are always scoped to the caller's own academicIssuerId (tenant-scope.ts) regardless of the academicIssuerId query filter -- passing a DIFFERENT issuer's id 404s exactly like an unknown one would (never a 403, never a silently-ignored filter that could be mistaken for "this issuer just has no templates"). Omitting the filter lists only the caller's own templates, never every issuer's. Sandbox mode performs no such scoping (no real per-client identity exists there at all).

Propose a new credential-template draft for the caller's institution

In production mode, academicIssuerId MUST be the institution the caller's own API key was issued against (tenant-scope.ts resolves this from the caller's Keycloak client_id) -- naming a DIFFERENT (even a real, APPROVED) issuer's id 404s exactly like an unknown one would, never a 403 that would confirm that issuer exists. Sandbox mode performs no such check (no real per-client identity exists there at all).

Submits a DRAFT template for Nexiel staff review (DRAFT -> PENDING_REVIEW)

In production mode, only submittable by the template's OWN issuer's API key -- a template that exists but belongs to a different issuer 404s exactly like an unknown template id would (tenant-scope.ts + templates.ts's submitTemplateForReview, same IDOR-safe convention as every other scoped route in this app). Sandbox mode performs no such check.

Nexiel-staff-only: approve or reject a PENDING_REVIEW template. Never callable with an institution's own API key.

Submit a new credential issuance batch (CSV or JSON rows) for maker-checker review

In production mode, academicIssuerId MUST be the institution the caller’s own API key was issued against (same cross-tenant scoping as the template routes) -- naming a different issuer 404s exactly like an unknown one would. Requires the credentials-api-issuer capability role, not just credentials-api-client.

Full batch detail, including every item and its sample/recheck status

A DIFFERENT signatory (the checker) re-keys a sampled item’s claim values for server-side comparison

Step-up-gated maker-checker approval -- transitions PENDING_APPROVAL to APPROVED, then hands off to the real background issuance worker

Requires a real, freshly-verified step-up assertion in the x-credentials-step-up-assertion header (see step-up.ts). The dashboard UI that produces this via a genuine Keycloak re-authentication round trip is Phase 5’s job -- this route and approveCredentialBatch both independently verify freshness server-side.

List credential verification sessions for the calling employer

Scoped to the calling employer: in production, the bearer token's authenticated identity -- `clientId` in the query string is IGNORED in that case. Never consumes disclosedClaims' one-time delivery, and never triggers a live revocationStatus re-check per row (reports each decision's own last-observed value instead) -- both deliberate "a bulk read must never have expensive/consuming side effects" choices, mirroring apps/verify-api's own LIST route precedent for the AML evidence pack.

Initiate an EUDI wallet academic-credential verification session (OpenID4VP)

Requires a credentials-api-verifier-scoped API key (an ordinary employer verification key, gated by KYB approval -- never a credentials-api-client or credentials-api-issuer key, both of which are issuer-side and structurally rejected here). Reuses the exact same OpenID4VP session pattern @nexiel/verify already implements for Nexiel Verify, parameterized by checkType (academic-credential | academic-enrolment-status).

Wallet's direct_post callback for an academic-credential verification session

This route's real authorization is the session's own unguessable state/nonce (OpenID4VP direct_post) -- a wallet holds no Nexiel API key, so no bearer token is required or checked here, exactly like apps/verify-api's identical wallet-callback route.

Read back a credential verification session's status and (if completed) its decision

The real delivery channel for disclosedClaims (never the wallet's own POST .../responses callback reply) -- delivered at most once (see `claimsDelivery` query parameter). revocationStatus is re-derived LIVE on every single read of THIS route, never cached -- see @nexiel/verify's status-list.ts.