Data protection

What Nomi holds about a credential holder, how it is isolated, and how to get it out.

Nomi holds the record behind somebody's membership card, badge, student ID or diploma. This page is the integrator's half of that: what you send, what you can get back, and where your key's boundary runs. The organisation's side — controls, key handling, incident response, and what has deliberately not been built — is on the Security and Privacy pages, written for a security team and kept current. Neither page claims a certification Nomi does not hold.

Isolation

• A key reaches one organisation and nothing else. There is no parameter that widens it, which is why no endpoint takes an organisation.
• An identifier from another organisation answers 404 — it does not exist as far as your key is concerned.
• Credentials, subjects, templates, webhook endpoints and events all inherit that boundary.

Send the minimum

A credential needs what it prints and what proves who holds it, and nothing else. attributes accepts whatever you put in it, which is exactly why a whole personnel or customer record ends up there by accident — send the fields a template actually reads, and leave the rest in the system that owns it. What is never sent cannot leak, cannot be exported and does not have to be deleted later.

Answering a request about one person

• GET /v1/subjects/{id} — everything held about them, plus a count of what they hold.
• GET /v1/credentials?subjectId=… — their credentials.
• GET /v1/credentials/{id}/events — what was done to each one, and by whom.
• DELETE /v1/subjects/{id} — for somebody who holds nothing. Anyone else is deactivated, because the record of what they held has to keep naming them.
• A signed export of the whole organisation's event record is available to an administrator from the console, for the cases a per-person answer does not cover.