Apple Wallet
How a credential becomes a signed pass, how it updates, and what your own certificate changes.
An Apple Wallet pass is a file: a signed .pkpass the device downloads and then holds. Once it is on the phone, the phone has a copy, and updating it means telling the device to come back for a new one.
Nomi runs all of that — the signing, the device registry Apple requires, and the push that tells a device its pass has changed. From the API's side you ask for the channel and watch its state.
A credential's Apple channel
{
"channel": "apple_wallet",
"state": "installed",
"installUrl": null,
"revision": 3,
"lastPushedAt": "2026-09-20T15:11:02Z"
}installUrl is null for Apple on purpose: Google hands out a signed save link, Apple hands out a file. The file is fetched from GET /v1/credentials/{id}/channels/apple_wallet/artifact, and the link your recipient actually receives comes from a distribution, which is what a QR code or an email should carry.
Channel states
| State | Means |
|---|---|
pending | Queued for rendering. The normal state right after issuing. |
provisioned | The pass exists and can be handed over. |
installed | A device registered for updates — somebody added it. |
stale | The credential changed; a new version is on its way to the device. |
failed | Rendering or signing did not succeed. Fix the cause and reprovision. |
removed | The holder deleted the pass from their wallet. |
POST/v1/credentials/{id}/channels/{channel}/reprovision
Queues the credential for re-rendering — after uploading signing material, or after a failure.
Your own certificate
Passes can be signed with your organisation's own Apple pass type certificate, so the credential is issued under your identity rather than under Nomi's. The material is uploaded in the console under signing, and nothing about the API calls changes.