SourceHut exposes separate services for Git, Mercurial, builds, tickets, lists, pages, and account metadata. Its GraphQL API decorates fields with OAuth access requirements, and personal access tokens can have a narrower scope than the account. That design is useful, but it makes a generic "API token" review too coarse.
On 2026-11-11 at 08:46:36 +08:00, title="SourceHut" returned 23 matches in a ZoomEye count-only query with page 1, page size 1, and sub_type=all. A body query for http.body="SourceHut" returned 804 matches at 08:46:38 +08:00. The links are the title query and the body query.
The body count is broad. It can include documentation, project pages, and hosted service references that are not the same deployment. The title count is narrow but can miss custom domains. Neither count proves that an API token is exposed.
Scope is part of identity
The SourceHut API documentation marks GraphQL fields with an access scope and a read or write kind. A client that can read a profile is not automatically able to read repositories, builds, or tickets. Some fields are also restricted to personal access tokens and are not available to a normal OAuth access token.
This creates a useful review sequence:
- 1.
Identify the client and the user who authorized it.
- 2.
List the services and fields it calls.
- 3.
Map each call to the documented scope.
- 4.
Confirm whether the client needs read or write access.
- 5.
Revoke or replace tokens that exceed the call graph.
The review should include CI jobs, bots, and command-line tools. A token created for a one-time repository import can become a long-lived credential in a build environment. A token with profile access may be harmless in isolation but dangerous when combined with a service that exposes account recovery data.
Personal tokens and OAuth tokens are different
The API schema distinguishes personal access tokens from OAuth access tokens for certain fields. That difference matters during incident response. A user may think that revoking an OAuth client removes all automation, while a personal token created for the same purpose remains active. Inventory both and record the owner.
The token documentation also links the token to the instance's API metadata and signing keys. Do not treat a copied token string as the only artifact. Record the instance, issuer, account, scope, creation time, and revocation path. If a token is found in a repository or log, remove it from the source location before assuming the incident is over; the history and any forks may still contain it.
Confirm the deployment before trusting the search
SourceHut can be hosted on a shared domain or a self-managed instance with a custom domain. A title search for the service name may miss a custom deployment, and a body reference may identify a project that merely uses a SourceHut service.
For each candidate, verify the GraphQL endpoint, the service identity, and the expected authentication response. Do not send a real token to an unverified host. The instance's API metadata can help identify the endpoint, but it is not a trust decision on its own. Compare the hostname with the organization's documented inventory.
A small, testable policy
Give each automation a named purpose and the smallest scope set that supports it. Separate read-only build reporting from write access to repositories or tickets. Set an expiration where the platform permits one, and test that a revoked token fails before the replacement is deployed.
The right output is not a count of "SourceHut instances." It is a table of confirmed endpoints, token owners, scopes, and revocation conditions. The ZoomEye observations are useful for finding public pages. The OAuth schema is what tells you whether a token can change code, tickets, or account metadata.