This page is for a university registrar or academic records office preparing to issue verifiable academic credentials, enrolment proofs, module completions, degree awards, into students' EU Digital Identity (EUDI) wallets through Nexiel Credentials. It explains the safety model behind batch issuance in plain terms and what your team needs to prepare. For an overview of Nexiel Credentials as a product, see Nexiel Credentials. For what a Nexiel-issued credential actually is and how the institution-vetting gate works, read how credential issuance works first if you have not already. For endpoint-by-endpoint detail, see the Credentials API quickstart.
Every credential batch your institution submits needs two different people: one who prepares it, and a different one who approves it. Nexiel enforces this at both the application level and the database level, so no single account can complete an issuance batch alone, however senior that account is.
A signed academic credential is not a draft. Once a student redeems it into a wallet, it exists as a cryptographically signed document a future employer or another university can independently verify, exactly as issued. A wrong degree title or an off-by-one award date should never depend on a single person's judgment, or a single compromised account, to catch it before it goes out.
Your institution registers at least two active signatories with Nexiel, typically the registrar, the head of academic records, or a quality assurance officer. Nexiel checks that at least two remain active at the exact moment a batch is approved, not only when your institution first onboarded, so a signatory leaving blocks approval until a replacement is registered. The signatory who prepares a batch can never also approve it, whether that happens by mistake or as an attempt to skip the second reviewer.
Nexiel will not allow a batch to be approved until at least 60 minutes have passed since it was submitted, timed from the moment of submission and never reset. A batch approved seconds after it was prepared has had no real second look, whatever the interface suggests happened in between. The window gives your second signatory genuine time to review, and Nexiel checks the clock again on the server at the moment of approval, not only once in an interface.
At the moment your institution submits a batch, Nexiel randomly selects roughly 10 percent of its valid rows, at least one row even for a small batch, for a mandatory recheck. That selection is fixed the instant the batch is submitted. Nothing later can change which rows were sampled.
A different signatory from the one who prepared the batch re-types the academic facts (the degree title, the award date, whatever your credential template asks for) for every sampled row, working from your institution's own source records. Nexiel compares what they typed against what was originally submitted. Approval is blocked until every sampled row has a matching recheck, and a mismatch on even one sampled row blocks the whole batch until it is resolved.
This catches the kind of error a spreadsheet produces silently: a row shifted by one, a value pasted from the wrong column, a name matched to the wrong award. Catching it here, before a credential is signed, is the only point at which catching it is free. A signed, wallet-held credential cannot be quietly corrected afterward.
A batch is a CSV file, or, for an institution with its own systems calling the API directly, a list of JSON rows, with one row per student. Two columns are always required: studentFullName and studentEmail. A studentDob or institutionStudentIdcolumn is optional, useful if your credential template's claims need a date of birth or you want to keep your own record identifier alongside the offer.
Every other column becomes an academic fact carried inside the credential itself, checked against the specific claim schema your institution's approved credential template defines. A degree award template asking for degreeTitle and awardDate expects exactly those two columns, and each row is validated against that schema the moment the batch is submitted:
studentFullName,studentEmail,degreeTitle,awardDate
Aoife Byrne,aoife.byrne@example-university.ie,BSc Computer Science,2026-06-15
Cian Walsh,cian.walsh@example-university.ie,BA History,2026-06-15A CSV column is always read as text, so a claim schema expecting a number rather than a string fails validation on a CSV upload. Submit that credential type as JSON rows through the API instead, where a real number can be sent directly. A row that fails validation is flagged and set aside. It does not block the rest of a genuinely valid batch.
Nexiel Credentials does not yet have a dashboard screen for uploading, rechecking, or approving a batch. Your institution's own developer or backend calls three endpoints directly: one to submit rows or a CSV, one for the second signatory to recheck each sampled item, and one to approve. See the Credentials API quickstart for the exact request and response shapes.
Your Nexiel dashboard already covers the two pieces of this that exist today: your credential templates, and your roster of registered signatories, including whether your institution currently has enough active signatories for a batch to ever be approved. Batch upload, recheck, and approval are on our roadmap for the dashboard.
Approving a batch also requires your signatory to freshly re-authenticate immediately beforehand, not just act inside an already-open session. Nexiel checks that the re-authentication is both real and recent, within about 60 seconds, before an approval can go through, independently of whatever the calling application already checked.
Once a batch is approved, Nexiel works through every valid row in the background, so a large batch never holds up the approval request itself. For each student, Nexiel creates a real OpenID4VCI (OpenID for Verifiable Credential Issuance) offer and emails that student a link to add the credential to their EUDI wallet. The offer link is valid for 14 days.
A student who opens the link has their wallet exchange a single-use code for a short-lived access token, then prove it holds the matching private key before Nexiel signs and returns the actual credential. Nothing in your batch is marked issued until a student genuinely completes that step. An offer nobody has redeemed yet stays exactly that: an offer, not a credential your institution can report as delivered.
If Nexiel cannot create an offer or send the email for a specific row, for example an unreachable address, that row is marked failed on its own, visible in the batch detail. A failure on one row never blocks the rest of the batch.
Nexiel reviews your institution once, at onboarding, and reviews each credential template once, when your institution first proposes it. Nexiel never approves a batch. That decision belongs entirely to your institution's own two registered signatories, for every batch you submit.