Is the any APIs to list the private models in the org and mapping it ot what has acces to it? by API

Beginners
1

is the any APIs to list the private models in the org and mapping it ot what has acces to it? how do I know what users is having access to what models? by API?

1 Like
4

Some operations can be performed via the HF API, while others cannot.

You can list private models in an org via the Hugging Face Hub API (and huggingface_hub’s HfApi).
But a complete “model → exact users who can access it” mapping is only possible if your org uses Resource Groups (Team or Enterprise). Otherwise, private repo visibility is effectively “org-wide”, so the best you can do is “model → all org members”.

Below is what’s possible, what isn’t, and the cleanest API-driven approach.

Background: what “access to a private model in an org” means on HF

On the Hub, a “model” is just a repo of type model.

Access control depends on which feature set you use:

Case A: No Resource Groups (common default)

  • Your org has members with roles like read / write / admin. (Hugging Face)
  • In this setup, private repos are not usually permissioned per-repo per-user. Practically, visibility is “org members can see private org repos”, and roles mainly affect write/admin capabilities. (Hugging Face)
  • Result: you cannot produce a meaningful per-model user list beyond “all org members”.

Case B: Resource Groups (Team or Enterprise feature)

  • Resource Groups let you scope visibility so that a private repo assigned to a resource group is only visible to members of that group. (Hugging Face)
  • Result: you can map model → resource group → users (and get a real per-model access list), but you must query Resource Group membership via API.

Also note: Resource Groups are explicitly a Team or Enterprise feature. (Hugging Face)

Part 1: List private models in an org (Python API)

Use HfApi.list_models(...) with:

  • author=<org>
  • expand=["private", "resourceGroup"] so each result includes privacy and (if applicable) resource group metadata (Hugging Face)

Example (works for listing)

# deps: pip install -U huggingface_hub
import os
from huggingface_hub import HfApi

ORG = "your-org"
api = HfApi(token=os.environ["HF_TOKEN"])  # token must be able to see the org's private repos

models_iter = api.list_models(
    author=ORG,
    expand=["private", "resourceGroup"],  # request extra fields from the server
)

models = list(models_iter)

private_models = [m for m in models if getattr(m, "private", False)]
print("private model count:", len(private_models))

for m in private_models[:20]:
    # Depending on client version, expanded fields may be attributes or live in __dict__
    rg = getattr(m, "resourceGroup", None) or m.__dict__.get("resourceGroup")
    print(m.modelId, "resourceGroup:", rg)

What you get:

  • private: bool is part of the returned model data (Hugging Face)
  • resourceGroup (when present) is an object that includes fields like id and name (Hugging Face)

Part 2: List org members (Python API)

You can list members with:

# deps: pip install -U huggingface_hub
import os
from huggingface_hub import HfApi

ORG = "your-org"
api = HfApi(token=os.environ["HF_TOKEN"])

members = api.list_organization_members(ORG)
# Returned objects are typically dict-like with at least username + role info
for m in members:
    print(m)

This method is part of the official HfApi surface. (Hugging Face)

Part 3: Map “model → who has access” (what is possible vs not)

What is possible (reliably)

1) If you are NOT using Resource Groups

You can only produce:

  • model → “all org members”

Because access is not meaningfully differentiated per model in the default org access scheme (roles are org-level). (Hugging Face)

So the mapping logic is:

  • List private models in org
  • List org members
  • For each model: accessible users = org members

That’s it.

2) If you ARE using Resource Groups (Team/Enterprise)

Then you can produce a real mapping:

  • model → resource group → users in that resource group

Because private repos assigned to a resource group are visible only to that group. (Hugging Face)

You already have the model’s resource group info via expand=["resourceGroup"]. (Hugging Face)
Next step is querying resource group membership.

The “Resource Groups” endpoints exist in the Hub OpenAPI under the resource-groups tag, and Resource Groups are explicitly called out as Team/Enterprise. (Hugging Face)

So the workflow is:

  1. List models (include resourceGroup)

  2. For each model:

    • if no resourceGroup: accessible users = org members
    • else: call Resource Group API to list users in that resource group

  3. Join into a final report

What is NOT possible (or not meaningfully defined)

1) “Give me, via one official API call, the exact list of users who can access each private model”

Not in the general case.

  • Without Resource Groups, “who can access model X” collapses to “org members”. (Hugging Face)
  • With Resource Groups, you can compute it, but it’s a multi-step join, not a single list-all ACL endpoint.

2) “Tell me what users have access” if you mean token-scoped, per-user effective access

HF tokens are user credentials. The server evaluates access based on the identity behind the token. There is no safe admin API that enumerates “effective access for every user to every repo” unless your org uses the access-control primitives (Resource Groups) that make it well-defined. (Hugging Face)

Practical way to discover the exact Resource Group endpoints (no guessing)

The official Hub OpenAPI spec is published at:

  • https://huggingface.co/.well-known/openapi.json (Hugging Face)

It explicitly includes a resource-groups section/tag. (Hugging Face)

So you can programmatically extract all Resource Group paths from the spec:

# deps: pip install requests
import requests

spec = requests.get("https://huggingface.co/.well-known/openapi.json").json()

rg_paths = []
for path, ops in spec.get("paths", {}).items():
    for method, op in ops.items():
        if isinstance(op, dict) and "resource-groups" in (op.get("tags") or []):
            rg_paths.append((method.upper(), path))

for method, path in rg_paths:
    print(method, path)

Then implement:

  • “list resource groups for org”
  • “get resource group members”
  • “add/remove member”
    using the exact endpoints you just printed.

This avoids relying on undocumented blog snippets or stale examples.

Enterprise note: SCIM is for provisioning, not per-model ACL by itself

If you are on Enterprise Plus, the OpenAPI spec includes a SCIM API to manage org users and “members’ access” in the identity-provider sense. (Hugging Face)
SCIM helps automate membership and groups, but you still need Resource Groups to make “which users can see which private repos” precise at the repo level. (Hugging Face)

Curated references

Summary

  • You can list private org models with HfApi.list_models(author=ORG, expand=["private","resourceGroup"]). (Hugging Face)
  • You can list org members with HfApi.list_organization_members(ORG). (Hugging Face)
  • Without Resource Groups, “who can access model X” is basically “org members”. (Hugging Face)
  • With Resource Groups (Team/Enterprise), you can map model → resource group → users via Resource Group endpoints from the OpenAPI spec. (Hugging Face)
5

Hi John,
Thanks for the response, I am doing this way, but weird thing is that,
Just wanted to inform, I have created token with org:read, but, when I read resource groups it does not list,
However, if I finegrained permission,
Resource Group
“Write access to resource groups in selected organizations” , it works,
so, my issue to you is that I should be able to read resource group without having write permission, this may be fixed. looks like a bug.

Is there any ways, I can list the access token metadata? For example, what are the access tokens exists by id & metadata, not the actual keys, besically to monitor them, is that possible?

thanks,
Jagadeesha