Skip to main content
The General Validation API accepts Microsoft Entra bearer tokens. People use the app in a browser with a delegated token from their Microsoft sign-in. Workloads call the API at https://api.generalvalidation.com with an application token issued for the General Validation API and one of the application roles described below. General Validation does not issue API keys. Your workload’s identity must live in the same Microsoft Entra directory as your Organization, and that Organization must already be activated by a person. The API resolves the Organization from the token’s verified directory; a supplied Organization identifier cannot select another Organization’s resources. Machine clients cannot activate an Organization or accept an invitation. An application role authorizes the workload without a membership record; a person still needs an active membership to use the app.

​
Application roles

Assign the lowest role the workflow needs. Roles are cumulative, and when a workload holds more than one, the highest recognized role applies. The API reference states the minimum role for each operation. No Fabric or OneLake permission is involved: the API holds none, and an application role grants none. Browsing workspaces and Tables, setting up the Environment, submitting a Run to Fabric, and reading exact values or mismatch evidence happen in the app with the signed-in user’s own Fabric access. See API and automation for what the API covers in this release.

​
Assign a role to your workload

Use a dedicated identity that your organization owns: a managed identity for an Azure workload, or an application registration with its own credential. An Azure subscription role such as Contributor does not grant API access. Roles are assigned on the General Validation API’s service principal in your directory. You need the API’s application (client) ID to assign a role and to request tokens. The API publishes it in the entraApplication security scheme of its OpenAPI document: x-gv-audience is the application ID and x-gv-scope is the scope to request. See API and automation for retrieving the document. If you cannot retrieve it yet, ask support@generalvalidation.com for the identifiers. For an application registration, an Entra administrator adds the General Validation API’s application permission for the chosen role to your application and grants admin consent. A managed identity has a service principal rather than an editable registration, so an administrator assigns the chosen role to that service principal directly. The following example assigns Reader to an existing managed identity when run by an administrator who can assign application roles:
Confirm that both lookups returned the intended IDs before submitting the assignment.

​
Acquire and send a token

For client credentials, request a token from your directory’s token endpoint using the caller’s own credential:
Request the scope published as x-gv-scope. It names the General Validation API resource and ends in /.default. For an Azure managed identity whose token request takes a resource or audience rather than a scope, use the same identifier without the /.default suffix. Requesting a scope does not grant an application role; the assignment above does. Tokens for the General Validation app itself are delegated user tokens for people signed in with a browser. The API rejects an application token issued for the app’s audience, so always request the API resource. Send the token over HTTPS on every request:
General Validation verifies the token’s signature, issuer, audience, lifetime, and application role, and confirms that the issuing directory is connected to an activated Organization. Keep token acquisition inside the workload, and keep credentials and tokens out of logs, screenshots, and source control. General Validation never receives your workload’s credential, only the token that Microsoft Entra issues.

​
Verify access

Start with the access resource, which returns the caller’s effective role:
The response’s principal reports kind as service_principal for a workload and effectiveRole as reader, contributor, or owner. A 401 response with the code auth.unauthenticated means the token was not accepted. A 403 response with the code auth.forbidden means the caller lacks the required role: review the role assignment, then confirm that the workload’s directory is the one where your Organization was activated. Every problem response carries a requestId; include it with the error code when you contact support@generalvalidation.com.

​
Change or revoke access

Remove the workload’s role assignment in your directory to stop newly issued tokens from carrying that access; a token already issued stays valid until it expires. Assign a different role the same way to change access. Manage the identity and its credential through your organization’s own workload lifecycle controls. For what the API returns and never returns, see the data boundary on API and automation.