Organizations and API keys
The commercial Validation Intelligence boundary has two related scopes:
- Organization: owns credentials and shares Validation Unit capacity across them.
- Credential: authenticates a caller and attributes its usage within the organization.
Calling POST /v1/validation requires both an active credential and an explicitly owned, active, provisioned organization. A recognized key is not sufficient if its organization cannot authorize validation.
Credential attribution and shared capacity
Every completed validation is attributed to the credential that performed it. Capacity enforcement, however, uses the organization's total configured capacity. Two credentials owned by the same organization therefore contribute to the same organization consumption total.
GET /v1/validation/usage/status returns the authoritative vu_v1 organization view and a credentials map containing per-credential credential_id, vu_consumed, workload_count, and validation_count data. See Usage and Limits.
Client restrictions
Credentials can restrict clients. Direct API calls default to client api when X-Ivorleaf-Client is omitted. If you send the header, its normalized value must be allowed for that credential or the API returns 403.
Client identity affects authorization and attribution; it does not change VI semantics or VU quantity.
Credential lifecycle
Missing, malformed, or unknown credentials return 401. An inactive, revoked, expired, or client-disallowed credential returns 403. An unprovisioned or inactive organization also returns 403 at the validation boundary.
Firebase identity is not a commercial validation credential. Older keys without explicit organization ownership can retain compatibility behavior on legacy surfaces, but their synthetic organization identity does not authorize /v1/validation.
The public portal does not expose credential creation, rotation, revocation, or organization-capacity administration. Request those operations through API access or Support.
Organization execution policy
The organization owns validation execution policy and usage. API keys authenticate into that organization and inherit its policy; credentials cannot select legacy or qualified evaluation. New production organizations default to qualified_v3, hybrid enabled, and vu_v1. Separate V3 entitlement is not required for normal new organizations. Key issuance, rotation, replacement, and revocation do not independently change that policy.
Customers integrate with Validation Intelligence; the underlying evaluator is not a customer configuration choice.