Skip to main content
Veridominus logo
Veridominus
Connecting to Jamf Pro

Use a Jamf API client you control and keep the connection path explicit.

Veridominus connects with Jamf API client credentials and bearer tokens. The connection path is direct from your Mac to your Jamf Pro environment. There is no developer-run relay or hosted review backend involved in routine product operation.

OAuth client credentialsDirect HTTPS to Jamf ProKeychain-backed secrets

Before you begin

  • Jamf Pro 10.35 or later, cloud or on-premise
  • Admin access in Jamf Pro to create API roles and clients
  • Veridominus installed on macOS 14 or later

TLS trust is standard macOS trust

On-premise Jamf environments using an internal or self-signed certificate can work, but the issuing root CA must already be trusted by macOS. Veridominus does not bypass TLS validation.

1. Create the Jamf API role

In Jamf Pro, go to Settings → System → API Roles and Clients → API Roles. Create a role that matches your intended use of Veridominus.

  1. Start with a review-only role if you are evaluating the product.
  2. Add extended read permissions only for the workflows you actually use.
  3. Add write privileges only for MDM command submission or script save-back.

Use the Permissions Reference for the exact workflow matrix.

2. Create the Jamf API client

  1. Go to Settings → System → API Roles and Clients → API Clients.
  2. Create a new API client and attach the role you just created.
  3. Copy the client ID and generate a client secret.

Client secret handling

Jamf only shows the client secret when it is generated. If you lose it, generate a new secret from the same API client instead of trying to recover the old value.

3. Add the server in Veridominus

  1. Open Veridominus and add a new server profile.
  2. Enter a profile name such as Production or Lab.
  3. Enter the Jamf Pro URL, including https:// and no trailing slash.
  4. Paste the client ID and client secret.
  5. Save the profile.

What happens after you save

Veridominus validates the session first, restores any local state tied to that server, and then continues loading the rest of the product data in the background. The app is designed to show startup phases explicitly instead of sitting on an indefinite blank or spinner state.

  • Session validation happens before the app enters the connected state.
  • Some read-heavy data loads are deferred so login does not block on tenant-wide scans.
  • Permission failures surface as blocked, partial, or unavailable workflows rather than hidden empty results.

Credential and token handling

  • Client credentials are stored in the macOS Keychain.
  • Tokens are obtained for the session and refreshed as needed.
  • Secrets are not written to plain-text local files.
  • Network traffic goes directly from the app to your Jamf Pro environment over HTTPS.

Common connection failures

ConditionWhat it usually means
401 UnauthorizedThe client ID or client secret is wrong, or the API client is disabled in Jamf Pro.
403 Insufficient PermissionsThe role is missing one or more privileges needed by the current workflow.
Connection timeoutThe Mac cannot reach the Jamf Pro URL over HTTPS, or the server is not responding in time.
TLS trust failureThe Jamf certificate chain is not trusted by macOS on this Mac.

Multiple server profiles

You can add more than one Jamf server profile. Each profile keeps its own credentials, local caches, and follow-up state so production, staging, and client environments stay separated.