{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihrsv7duaatg5iouhq23axyr4li7fe6weggd6xjxesuerwhfmfvv4",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mn7egxfo54r2"
  },
  "path": "/t/how-to-make-an-organization-access-token/176432#post_3",
  "publishedAt": "2026-06-01T04:15:37.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "User Access Tokens docs",
    "Access control in organizations",
    "User Access Tokens",
    "Organization API token deprecation",
    "huggingface_hub/_login.py",
    "huggingface_hub authentication docs",
    "https://huggingface.co/settings/tokens",
    "huggingface_hub quickstart",
    "environment variable docs",
    "Create and manage a repository",
    "Upload files to the Hub",
    "HfApi client docs",
    "GitHub Actions docs",
    "huggingface_hub issue #821",
    "Tokens Management docs",
    "Inference Providers",
    "Inference Providers pricing docs",
    "gated models docs"
  ],
  "textContent": "This can get pretty tangled pretty quickly:\n\n* * *\n\nI’m not Hugging Face staff, so please treat this as a community answer. But based on the current docs and the older staff discussion around organization tokens, I would not start by looking for a new “organization access token” for this Colab upload workflow.\n\nFor normal Hub uploads from Colab / `huggingface_hub` / CLI, the usual path is:\n\n> Use a **User Access Token** from a user account that has access to the organization.\n>  The organization part comes from that user’s organization membership/role, and, for fine-grained tokens, from the token’s resource scope.\n\nSo the short version is:\n\nGoal | What I would use\n---|---\nPush model files from Colab to an org repo | A **User Access Token** with `write` permission, or preferably a **fine-grained** token scoped to the target org/repo\nPush to `my-org/my-model` | Use `repo_id=\"my-org/my-model\"`\nAvoid a broad token in a shared notebook / CI | Use a fine-grained token scoped as narrowly as possible\nLong-lived automation not tied to one employee | Consider a dedicated “machine user”-style account + fine-grained token\nTeam/Enterprise org with token policies | Check whether the org requires fine-grained tokens or admin approval\n\n## 1. The main point: token permission and org role both matter\n\nThe current User Access Tokens docs say that User Access Tokens are the preferred way to authenticate an application or notebook to Hugging Face services.\n\nThey also describe the practical permission model:\n\n  * `read` token: can read repos that the user can read.\n  * `write` token: can additionally create/push/modify repos that the user has write access to.\n  * `fine-grained` token: can be restricted to specific resources, such as selected repos or organization resources.\n\n\n\nFor organization repos, there are two separate checks:\n\nLayer | Example question\n---|---\nUser’s org role | Is this user allowed to write/admin this organization or repo?\nToken permission/scope | Does this token allow write access to this target resource?\n\nA useful mental model is:\n\n> Effective access = **user/org permissions** ∩ **token permissions/scope**\n\nSo, for example:\n\nUser/org situation | Token situation | Likely result\n---|---|---\nUser has only org `read` role | `write` token | Still not enough to push\nUser has org `write` or `admin` role | `read` token | Still not enough to push\nUser has org `write` or `admin` role | `write` token | Should work for normal repo push, assuming repo/type/path are correct\nUser has org `admin` role | fine-grained token not scoped to the target repo/org | May fail with 403 or repo-not-found-like behavior\nUser has org `admin` role | fine-grained token scoped correctly | Usually the safer production/shared-notebook path\n\nThe org role side is described in Access control in organizations, where org members can have roles like `read`, `contributor`, `write`, and `admin`. The token side is described in User Access Tokens.\n\n## 2. Why “organization access token” is confusing here\n\nThere is older wording and older behavior around organization API tokens, so the confusion is understandable.\n\nThe important historical context is this forum thread:\n\n  * Organization API token deprecation\n\n\n\nIn that thread, Hugging Face staff explained that organization API tokens were on a deprecation path, and that scoped tokens were intended as the replacement direction before fully removing org-token support. The same staff reply also mentions the common workaround for non-human automation: use a dedicated `machineuser`-style account and that account’s token.\n\nThat maps pretty closely to the current practical answer:\n\n  * For a human user in Colab: use that user’s User Access Token.\n  * For safer automation: use a fine-grained User Access Token.\n  * For automation that should not die when an employee leaves: use a dedicated machine-user-style account, then create a token from that account.\n  * For Team/Enterprise cases: also check organization token policies.\n\n\n\nAlso, the Python client itself points in this direction. In `huggingface_hub`, `login()` rejects old `api_org...` organization tokens and tells you to use a personal account token instead:\n\n  * huggingface_hub/_login.py\n  * huggingface_hub authentication docs\n\n\n\nSo for a Colab / `huggingface_hub.login()` / normal upload workflow, I would not try to create or use an old organization token.\n\n## 3. Practical Colab path\n\n### Option A: simple one-off test\n\nFor a quick test, create a User Access Token with `write` permission from:\n\nhttps://huggingface.co/settings/tokens\n\nThen make sure the user who owns that token has enough permission in the organization, usually `write` or `admin`.\n\nIn Colab, store the token as a Colab secret or environment variable, commonly `HF_TOKEN`.\n\nThe huggingface_hub quickstart says `HF_TOKEN` can be used for authentication and that Colab supports private keys/secrets for notebooks. The environment variable docs also say `HF_TOKEN` overrides the token stored on the machine.\n\nA minimal upload pattern would look like this:\n\n\n    # pip install -U huggingface_hub\n\n    import os\n    from huggingface_hub import HfApi, create_repo, whoami\n\n    token = os.environ[\"HF_TOKEN\"]\n\n    # Check which HF account this token belongs to.\n    # Do not print the token itself.\n    print(whoami(token=token))\n\n    repo_id = \"<org-name>/<repo-name>\"\n\n    create_repo(\n        repo_id=repo_id,\n        repo_type=\"model\",\n        private=True,\n        exist_ok=True,\n        token=token,\n    )\n\n    api = HfApi(token=token)\n    api.upload_folder(\n        folder_path=\"<local-output-folder>\",\n        repo_id=repo_id,\n        repo_type=\"model\",\n    )\n\n\nThe important details are:\n\nDetail | Why it matters\n---|---\n`repo_id=\"<org-name>/<repo-name>\"` | The namespace is part of `repo_id`; do not push to your personal namespace by accident\n`repo_type=\"model\"` | Use the right repo type: `model`, `dataset`, or `space`\n`token=token` | Makes it explicit which token Colab is using\n`whoami(token=token)` | Confirms the token owner; browser login and Colab token can be different identities\n\nFor the repo/upload API details, see:\n\n  * Create and manage a repository\n  * Upload files to the Hub\n  * HfApi client docs\n\n\n\n### Option B: safer shared notebook / CI pattern\n\nFor anything shared or long-lived, I would prefer a fine-grained token:\n\n  1. Create a fine-grained User Access Token.\n  2. Scope it only to the target organization/repository if possible.\n  3. Give it only the permissions needed for the job.\n  4. Store it as a secret, not directly in the notebook.\n\n\n\nThis is also the direction suggested by the GitHub Actions docs, which say to create a Hugging Face access token with write permission to the target repo and, for better security, use a fine-grained token scoped only to the repository being synced.\n\n## 4. Avoid older examples using `organization=...`\n\nSome older examples and issues mention an `organization=` argument. I would avoid mixing that mental model with the current `repo_id` form.\n\nPrefer this:\n\n\n    repo_id = \"<org-name>/<repo-name>\"\n\n\nrather than trying to pass the org separately.\n\nThere is an old `huggingface_hub` issue showing how mixing `repo_id` with the deprecated `organization` argument could cause confusion:\n\n  * huggingface_hub issue #821\n\n\n\nFor a normal current workflow, `repo_id=\"<org>/<repo>\"` is the low-confusion form.\n\n## 5. Troubleshooting table\n\nSymptom | Most likely checks\n---|---\n`401 Unauthorized` | Token missing, invalid, deleted, not loaded in this runtime\n`403 Forbidden` | Token lacks write/scope, user lacks org permission, org token policy blocks this token, token pending/denied/revoked\n`Repository Not Found` | Wrong `repo_id`, wrong `repo_type`, private repo not accessible to this token, stale/wrong token\nWorks in browser but fails in Colab | Browser session and Colab token are different identities\nUser is org admin but push still fails | Token may be read-only, fine-grained scope may not include target repo, or Team/Enterprise token policy may apply\n`login()` rejects the token | You may be trying to use an old organization token instead of a User Access Token\nInference calls fail but uploads work | Inference Providers permissions are separate from Hub repo write permissions\nInference usage bills personal account | Billing is separate from authentication; see `bill_to` / `X-HF-Bill-To` for Team/Enterprise Inference Providers billing\n\nHelpful checks:\n\n\n    import os\n    from huggingface_hub import whoami\n\n    token = os.environ.get(\"HF_TOKEN\")\n    print(\"HF_TOKEN present:\", bool(token))\n\n    if token:\n        print(whoami(token=token))\n\n\nAnd from CLI:\n\n\n    hf auth whoami\n    hf auth list\n\n\nDo not print or paste the actual token into a public notebook, forum post, or issue.\n\n## 6. Team/Enterprise orgs can add another layer\n\nIf the organization is on Team/Enterprise, token policy can matter.\n\nThe Tokens Management docs describe policies such as:\n\nOrg token policy | Effect\n---|---\nAllow access via User Access Tokens | Normal read/write and fine-grained tokens can be authorized\nOnly access via fine-grained tokens | Broad `read`/`write` tokens are rejected for org resources\nRequire administrator approval | Fine-grained tokens may need org admin approval before access works\n\nThe User Access Tokens docs also describe the member-side behavior: pending, denied, revoked, and fine-grained-only policy cases can produce `403` errors against organization resources.\n\nSo if everything looks correct but you still get `403`, check whether the org has a token policy requiring fine-grained tokens or administrator approval.\n\n## 7. Separate concepts that often get mixed in\n\nThese are related but not the same as “push model files to an org repo”.\n\n### Inference Providers permission\n\nCalling Inference Providers is not the same permission as pushing files to a Hub repo. Inference Providers may require a separate fine-grained permission such as making calls to Inference Providers.\n\nDocs:\n\n  * Inference Providers\n\n\n\n### Organization billing for inference\n\nIf the reason you are looking for an org token is billing for Inference Providers, that is a separate concept. The Inference Providers pricing docs say that each user still uses their own User Access Token, while organization billing can be selected with `X-HF-Bill-To` or `bill_to` for Team/Enterprise organizations.\n\nSo:\n\nConcept | Mechanism\n---|---\nAuthentication identity | User Access Token\nOrg repo write access | User’s org role + token permission/scope\nInference billing to org | `X-HF-Bill-To` header or `bill_to` parameter, where supported\n\n### Gated models\n\nGated third-party models are another separate case. The gated models docs explain that access requests are granted to individual users, not to an organization as a whole.\n\nSo an org token mental model can be especially misleading there: the token owner must be the user who has accepted / been approved for the gate.\n\n## 8. My practical recommendation\n\nFor your specific Colab upload case, I would try this order:\n\n  1. Confirm your HF account is a member of the org and has `write` or `admin`.\n  2. Create a User Access Token.\n     * For a quick test: `write`.\n     * For safer usage: fine-grained, scoped to the target org/repo.\n  3. Put it in Colab as `HF_TOKEN`.\n  4. In Colab, run `whoami(token=token)` to confirm the token identity.\n  5. Use `repo_id=\"<org-name>/<repo-name>\"`.\n  6. Use `repo_type=\"model\"` if this is a model repo.\n  7. If you get `403`, check token scope, org role, and Team/Enterprise token policy.\n\n\n\nThe main thing I would not do is spend time trying to find a new organization token for `huggingface_hub.login()` or a normal Colab upload. The supported/default path is a User Access Token whose effective access comes from both the token and the user’s organization membership.",
  "title": "How to make an organization access token?"
}