Skip to main content
GET
Use this endpoint to find out which capabilities an account, reseller or organization may actually use, so your integration can hide a feature instead of letting a user reach a write that fails with 403 forbidden. Availability is governed by Feature Administration, where a Partner or Reseller locks a feature for the levels beneath it. A lock is inherited: one placed on an account applies to every reseller and organization under it, and one placed on a reseller applies to all of its organizations.

Choosing a scope

Pass at most one scope parameter. Supplying both, or supplying one with an empty value, is rejected with 400. Use organization_id when deciding what to show for a specific customer — it is the only scope that reflects the full inheritance chain. The account-level view is deliberately coarser: it reports only the locks that reach everything beneath, because an access token identifies an account rather than one organization.

Query Parameters

string
Optional. Report availability for this organization, applying its account, reseller and organization-level locks. The organization must belong to the authenticated account, or the request is rejected with 404. Mutually exclusive with reseller_id.
string
Optional. Report availability for this reseller, applying its own locks and those it inherits from the account. The reseller must belong to the authenticated account, or the request is rejected with 404. Mutually exclusive with organization_id.

Response Fields

Each entry in data:

decided_by

Integration features are the exception to the regime split: the account’s integration allow-list still applies even while Feature Administration is on, so an integration.* entry can report legacy_column in either regime — as the example response above shows for integration.slack.

Governing regime

feature_administration_enabled reports which of two regimes is in force platform-wide: the Feature Administration matrix, or the older per-account and per-organization settings that preceded it. The same feature can be governed differently under each, so the field is included for callers that compare responses over time or raise a support ticket about one. It does not change how you use the response: state is always the answer that applies right now, under whichever regime is active.

Two things to build around

LLM models. An llm.* feature reported as available means the model may be assigned to the organization’s agents; locked means a Partner or Reseller has withheld it. The always-available floor model (gpt-4.1) has no llm.* row because it can never be locked. The same answer, shaped for building a picker, is available from GET /v1/llm-models.
Opt-in features report permission, not state. For secure_access, phi_redaction and use_reseller_smtp, available means the organization is permitted to switch the feature on — not that it currently is. Locking these prevents a new opt-in; it never turns the feature off for an organization already using it.

Errors