Credential Management
The HID Origo Credential Management API enables issuance and lifecycle management of digital credentials for access control.
A Pass concept is used to represent these digital credentials. A Pass can be thought of as a digital copy of a physical access badge, complete with credentials and visual elements such as artwork. Every Pass is based on a Pass Template that specifies the type of credential(s) to include, along with card artwork, support contact details, platform-specific settings and other metadata.
Support limited to Apple Wallet, Google Wallet and Identity Positioning
This API currently only supports Seos credentials in Apple Wallet, Google Wallet and Identity Positioning credentials. Support for other platforms, such as the HID Origo and Seos SDK may be added in future releases.
User Records
The Credential Management API does not provide any ability to create or manage user records. User resources referenced by userId are created and managed using the User Management API.
Specification
Release Notes
This section provides a version-wise summary of updates to the Credential Management API, including new features, improvements, and bug fixes. It is intended to give visibility into changes across releases and help API consumers/partners to understand updates that may be relevant to their integration or usage.
3.3.5
Version 3.3.5 includes the following PPPU changes:
PPPU behaviour update (Apple)
- PPPU, first introduced in release 3.1.0, remains supported for updating mobile wallet passes after issuance (for example, Apple Wallet).
- In this release we simplify the PPPU workflow and state handling by:
- Removing legacy intermediate PPPU request states (for example, REQUESTED, ACCEPTED and related transitions).
- Deprecating and removing the PPPU cancellation API (
DELETE /organization/{organization_id}/pass-update/{pass_update_id}), as PPPU update requests cannot be cancelled once they have been accepted by the platform (after a successful PATCH /passes/{passId}).
- Ensuring that:
- A successful
PATCH /passes/{passId}call means the update request has been fully validated and accepted by the platform. - After acceptance, the PPPU update proceeds asynchronously to a terminal outcome (COMPLETED or FAILED).
- The final credential result (ISSUED, FAILED, etc.) continues to be driven asynchronously and exposed through the existing status fields and event/callback mechanisms.
- A successful
The public API endpoints and payload shapes remain unchanged; this is a behaviour and lifecycle alignment, not a payload change.
Google Wallet PPPU (new platform support)
- PPPU is now supported for Google Wallet, reusing the same PATCH /passes/{passId} pattern already used for mobile wallet PPPU.
- Customers can now:
- Add or remove credentials on an already‑issued Google Wallet pass.
- Avoid revoking and re‑issuing passes for changes that can be handled via PPPU.
- PPPU behavior for Apple Wallet and Google Wallet is aligned:
- Same PATCH /passes/{passId} pattern.
- Same approach to validation at PATCH time and asynchronous final status handling.
- For API details, see: Credential Management - HID Origo API Documentation
PPPU for Apple Wallet introduced in 3.1.0 continues to be supported with a simplified state flow, and PPPU is now also available for Google Wallet, using the same API pattern. Legacy PPPU intermediate states are removed. Partners using the deprecated PPPU cancellation endpoint must remove any dependency on it.
NOTE: (Apple vs Google callbacks): For Apple Wallet, PPPU currently emits an intermediate event plus the final PASS_UPDATED event; for Google Wallet, PPPU emits only a single final PASS_UPDATED event. This difference does not block core business flows and is tracked internally to evaluate callback enrichment and long‑term event model alignment.
Additional API Enhancements in v3.3.5:
- Improved Google Pass Naming Control:
- The display name of the access badge in Google Wallet can now be set independently from the ISSUER_ID parameter configuration on the HID Origo account, as required by Google Wallet.
Resolved Issues ( Bug fixes)
- Credential Template Update Behaviour
- Fixed an issue where patching the Credential Template value in an existing pass template did not properly replace the old value, causing both the previous and new values to remain. The patch mechanism now correctly overwrites the existing Credential Template value.
- User Photo Processing Stability
- Resolved a problem where processing certain large user profile images could fail. Robust Image Handling is introduced to ensure stable and reliable processing for all supported image sizes.
- credentialContainerId Data Type Correction
- Updated the API specification to correct the format of credentialContainerId, which is now documented as a string identifier instead of a UUID.
3.3.4
Version 3.3.4 includes the following changes:
Google Work Profile Support
HID Mobile Access now supports Google Work Profile environments.
- Passes provisioned from the provisioning application installed within the device's Work Profile are seamlessly delivered to the Google Wallet application in the corresponding Personal Profile.
- A single Google Wallet app, installed within the personal profile, is sufficient for the device, ensuring familiarity, convenience, and consistency with the user's preferred storage for all their Google Wallet passes.
- Facilitates the seamless and secure provisioning of access passes within Google Work Profile environments for managed corporate accounts, which may necessitate the installation of Mobile Device Management (MDM) software.
The Work Profile facilitates the separation of corporate-mandated software installations without granting control over, or access to, applications and content within the user's personal profile
3.3.3
Version 3.3.3 includes the following changes:
- Introduced additional optional attributes in Pass Template and User Management.
- These attributes can now be referenced within Credential Management and User Management, enabling more flexible configuration and extension support.
- Provisioning platforms that support these attributes will automatically recognize and display them when they are passed. with no impact to existing behaviour or additional setup required.
- This enhancement improves alignment across credential handling and user data, providing flexibility for upcoming extensions and customization needs.
3.3.2
Version 3.3.2 includes the following changes:
- HID now supports a second digitization for Google Wallet, allowing users to seamlessly provision their digital access card to both a smartphone and a wearable device with support for up to two devices. This enhancement improves the user experience by supporting multiple personal devices, offering greater flexibility and convenience. It expands the use cases for digital wallet credentials, meeting the growing demand for cross-device access.
3.3.1
Version 3.3.1 includes the following changes:
- HID has enhanced its support for high-resolution user photo uploads (e.g., 1242×1242 px) on wallet passes by introducing platform-specific dynamic downscaling and extended validation workflows for wallet customers. This enhancement ensures that images are automatically resized to meet each platform’s requirements, delivering optimal resolution rendering across both Apple Wallet and Google Wallet.
- Note: Common image formats, such as PNG, JPEG, JPG can be uploaded; however, the preferred format for the wallet is PNG. If a user uploads a JPEG or JPG, the system will accept it and automatically convert it to PNG format. For all GET operations, the photo will consistently be returned in PNG format.
3.3.0
Version 3.3.0 includes the following changes:
- HID now supports the display of declining balances for credentials provisioned via Google Wallet. This enhancement allows authorized integration partners to push real-time balance updates directly to HID, which are then reflected in the user’s Wallet pass. Currently supported for Google university customers only
- Note: HID does not process transactions or calculate balances. Only displays the latest balance value. This functionality is only supported on mobile phones - it is not available on wearables such as smartwatches. To enable this functionality, please reach out to your Technology Partner Team for assistance and integration guidance.
3.2.9
Version 3.2.9 includes the following changes:
- We are pleased to announce that support for CampusID customers with Google Wallet is now available.
3.2.8
Version 3.2.8 includes the following changes:
- We are excited to announce the availability of the new Web Push Provisioning API for Apple Wallet and Google Wallet.
- This functionality enables administrator-initiated provisioning for Apple Wallet and Google Wallet, without the need to download and install a provisioning application on the user's device.
Please note : For implementation guidance or to enable this feature for your organization, please contact your integration partner team
3.2.7
Version 3.2.7 includes the following changes:
- Pass Design: We are excited to introduce support for pass design functionality, enabling seamless integration of SEOS credentials with
- Google Wallet
- Apple Wallet:
- Note: Seamless Pass design integrations from HID Origo to Apple's Business Registry are not supported yet. Further updates will follow as support for this is extended. Please contact your HID representative to assist with manual updates required.
- User Photo ID: User photo uploads are now supported on wallet passes. Only images with exact dimensions of 1242 X 1242 px will be accepted. The supported format for the photo is PNG.
3.2.6
Version 3.2.6 includes the following changes:
- Google Wallet now supports storing multiple credentials in a single pass.
3.2.5
Version 3.2.5 includes the following changes:
- Documentation fix: Scope attribute excluded from the header for PASS Delete and Update API.
3.2.4
Version 3.2.4 includes the following changes:
- The device-limit configuration is being moved from the pass-template configuration level to the organization-level configuration. As a result, the
pushProvisioningPolicyattribute is being removed from the pass-template API request and response.
3.2.3
Version 3.2.3 includes the following changes:
- Introducing optional boolean attribute
primaryin the User Management API email section, indicating the user's primary email address. - Introduces a new API for deleting credential once it has been issued.More information can be found in the Credentials section under the
Deleteendpoint request.
3.2.2
Version 3.2.2 includes the following changes:
- Introduces search user API with limited search options. Only supports
externalIdsearch. - For more information, see the
../.searchendpoint in the User Management API. - Introducing the
pushProvisioningPolicyattribute for creating and modifying pass-template requests, which enables support for device limit features. For more information, see the Pass Template with Device Limits section under create and patch pass-template. - Introducing the new field
$.deviceTypein Pass resources, indicating the provisioned device type for the pass. - Introducing
$.Namefields when pass-template is created and update request, and credential template requests. - Added IDENTITY_POSITIONING application profile in
$.profilefor credential templates requests
3.2.1
Version 3.2.1 includes the following changes:
- Added support for issuing a single Identity Positioning Credential in a Pass. Refer to the Pass Template with Identity Positioning Credentials example under the create Pass Template section.
- Added an application profile POSITIONING_BEACON in
$.profile
3.2.0
Version 3.2.0 includes the following changes:
- Added support for Google Wallet. Usage of this feature requires adding the mandatory
googleWalletConfigurationfields to an existing or new Pass Template. For more information, see all the methods of the../pass-templateendpoint. Provisioning and lifecycle management APIs are unaffected by this change. - Initial launch supports only one set of credentials to be stored in a Google Wallet pass.
- Added support for displaying role on Passes in Google Wallet. This value is sourced from the
rolesproperty of the user record in the User Management API.
3.1.1
Version 3.1.1 includes the following changes:
- Added support for configuring a default Pass Template. For more information, see the
POSTandPATCHmethods of the../pass-templatesendpoint.
3.1.0
Version 3.1.0 includes the following changes:
- Introduces a new set of extension APIs to support updating credential data and metadata associated with a
Passafter it has been issued. Refer to thePATCHmethod for the../pass/{pass_id}endpoint for details. - Introduces a new field
$.updateStatustoPassresources to indicate that the pass is being updated when its value is other thanNONE. - Introduces a new field
$.platformTypetoCredentialresources to indicate the platform the credential was provisioned to. For example,APPLE_WALLET. - Introduces two new fields
$.platform.typeand$.platform.storageTypetoCredentialContainerresources to indicate provisioning platform and storage type. - For
CredentialContainerresources, the attribute$.idformat was changed fromstring($uuid)tostring.
3.0.6
Version 3.0.6 introduces two new fields to Credential resources:
$.credentialIdentifiers[*].keyset: indicates which keyset was used for the Secure Object$.profile: indicates which application profile was used for the Credential
3.0.5
Version 3.0.5 includes the following changes:
- Added support for issuing multiple Credentials in a single Pass. Refer to the Pass Template with Multiple Credentials example under the create Pass Template section.
- Added support for displaying an abbreviated name on Passes in Apple Wallet. This value is sourced from the
displayNameproperty of the user record in the User Management API. - Added
ISSUEDstatus for Credential resources.
3.0.4
Version 3.0.4 of the API includes the following changes:
- Added
CANCELLEDstatus for Pass resources which is used when a Pass is deleted without reaching anACTIVEstate. - Added boundary conditions and updated required items for several schemas.
- Corrected pagination default values.
3.0.3
Version 3.0.3 of the API includes the following changes:
- Removed explicit
AcceptHTTP header parameters, since only a single version is supported. - Updated sample for updating Pass Template: it is now possible to update the
organizationName. - Updated Credential Template definition to match the implementation. A
metaDatafield is now included. - Removed the
../credential-container/{credential_container_id}/credentialendpoint, as the same information is available on the Credential Container.
Glossary
| Term | Definition |
|---|---|
| Application-ID | The Application Identifier is used to identify an application calling HID Origo APIs. This value is provided by HID Partner Services. Please refer to Authentication for additional details. |
| Credential | Represents an access control credential. |
| Credential Container | A device capable of holding one or more credentials. Includes mobile phones, smart watches, wearables and cards. The passInstances and credentials are mutually exclusive. |
| Issuance Token | A one-time password used to retrieve provisioning instructions and data using the HID Origo SDK. The format/structure of the token is subject to change (but will remain a string). |
| Pass | Represents a digital access card, which may contain one or more credentials. |
| Pass Template | Defines a template for digital access cards. Controls credential types, artwork and other metadata. |