API Service Accounts provide non-interactive identities for client-owned applications. They are separate from human users and browser sessions. An active API Service Account can call all public integration APIs made available by the installed version and licensed Modules and Sub-modules.
Choose the correct authentication
Use a signed-in administrator with service_accounts:manage to create, rotate, or revoke an API Service Account in
Settings → API Service Accounts. Use the generated API key only from the client-owned application that calls a
supported OneView API.
Do not use a person's email/password, browser session, setup token, license or activation value, or vendor credential as an integration API key.
Create an API Service Account
- Open Settings → API Service Accounts.
- Enter a name that identifies the application, environment, owner, and purpose.
- Choose an expiry date, or select a non-expiring credential when client policy permits it.
- Create the account and immediately copy the key into the client's approved secret manager.
The complete key is shown once. If it is lost before being stored safely, rotate the account to issue a replacement. Do not search browser storage, logs, backups, or the database for it.
Use search to find an account by its approved name or displayed key prefix. Use the status filter to review active, expired, or revoked accounts.
Call a supported API
Client-owned software sends the key over HTTPS:
POST /api/verifications/<licensed-sub-module>
Authorization: Bearer <service-account-api-key>
Content-Type: application/json
Idempotency-Key: <unique-non-personal-operation-key>
The installation's license, installed Modules and Sub-modules, capacity, vendor connection, and service rules still apply. The idempotency header is optional, but using a unique non-personal key for each logical verification protects network retries. Omission always creates a fresh vendor request. Never place a subject identifier or other personal data in the header. See Synchronous verification API for the supported request and response contract.
API Service Accounts are not assigned dashboard roles. They cannot use the browser dashboard or call setup, administration, user, role, branding, network, license, software-update, or API-credential-management endpoints. Those functions remain available only through their documented human or host-administrator workflows.
Rotate a credential
Rotation invalidates the previous key immediately:
- Schedule a short integration maintenance window.
- Rotate the account and save the show-once replacement in the approved secret manager.
- Deploy the replacement without placing it in source control, logs, tickets, or chat.
- Run one provider-approved synthetic verification.
- Confirm the old credential no longer authenticates and review the activity log.
If the replacement is lost, rotate again and record why. An expired or revoked account cannot be restored by rotation; create a new least-privilege account and retire the old integration record.
Revoke an account
Revoke immediately after suspected exposure, unexpected use, owner departure, or integration retirement. Revocation stops the key from authenticating. A revoked account cannot be rotated.
If an action appears to fail, refresh the list and activity log before creating a duplicate account. Record the safe error code, account name, and time; never copy the complete key or verification data into support evidence.
Client responsibilities
- Use a different account for each application and environment.
- Use the credential only with documented public integration APIs made available by the installed licensed Modules and Sub-modules.
- Keep keys in an approved secret manager.
- Restrict network access and monitor ownership, expiry, last use, and failed authentication.
- Rotate before expiry and whenever staff, systems, or trust boundaries change.
- Revoke immediately after leakage, unexpected use, compromise, or decommissioning.