TL;DR: There is no isTotal field anywhere in the GitHub GraphQL API. It has never existed in any version of the schema. If you want a count of items, the field you're looking for is totalCount, an Int! that lives on GraphQL Connection types (like IssueConnection, StargazerConnection, RepositoryConnection). The one notable exception is search, which uses type-specific counters such as issueCount and repositoryCount instead.

If you searched for the GitHub GraphQL API isTotal field, you probably hit an error like Field 'isTotal' doesn't exist on type '...' and assumed the field was renamed, deprecated, or hidden behind a permission. None of that is the case. The name is simply wrong. This article explains what the real field is, why the confusion happens, how to use totalCount correctly, and how to verify any field yourself in ten seconds so you never guess again.

Is there an isTotal field in the GitHub GraphQL API?

No. The GitHub GraphQL schema contains zero fields named isTotal. The correct field for counting the items in a connection is totalCount, typed as Int!. Its official schema description is: "Identifies the total count of items in the connection." Any query using isTotal will fail schema validation before it runs.

That's the direct answer. Now here's the context that actually makes it useful.

What totalCount really is

GitHub's GraphQL API models lists as connections — the standard Relay-style pagination pattern. A connection wraps a list and exposes a small, predictable set of fields:

• edges — the list, each edge holding a node and a cursor
• nodes — a shortcut to the underlying objects
• pageInfo — cursors and hasNextPage / hasPreviousPage flags
• totalCount — the total number of items in the whole connection, not just the current page

So totalCount is not a special or gated feature. It's a plain field you select like any other. Because GraphQL only returns what you ask for, you have to request it explicitly — which is exactly why a wrong name like isTotal fails instead of silently returning nothing.

Here's the shape of a real connection type, straight from the schema:

type IssueConnection {   edges: [IssueEdge]   nodes: [Issue]   pageInfo: PageInfo!   totalCount: Int!   # "Identifies the total count of items in the connection." }

How to count items with totalCount (working examples)

The pattern is always the same: reach a connection field, then select totalCount. You do not need to fetch any nodes to get the count.

Count open and closed issues in a repository:

query {   repository(owner: "octokit", name: "graphql.js") {     openIssues: issues(states: OPEN) { totalCount }     closedIssues: issues(states: CLOSED) { totalCount }   } }

Count stargazers and forks:

query {   repository(owner: "octokit", name: "graphql.js") {     stargazers { totalCount }     forks { totalCount }   } }

Count a user's public repositories:

query {   user(login: "octocat") {     repositories(privacy: PUBLIC) { totalCount }   } }

Notice the alias trick in the first example (openIssues: / closedIssues:). Because you can query the same connection with different arguments, aliases let you pull several counts in a single request — one of GraphQL's biggest wins over REST.

The one exception: search doesn't use totalCount

If you're counting search results, totalCount is not available. The search connection returns a SearchResultItemConnection, which exposes six type-specific counters instead:

Example:

query {   search(query: "repo:octokit/graphql.js is:issue is:open", type: ISSUE, first: 0) {     issueCount   } }

One important caveat straight from the schema: each of these counters reflects the true number of matches, but the search API will only ever let you page through a maximum of 1,000 results across all types. So issueCount might report 5,000 while you can retrieve only 1,000 of them. That's a documented platform limit, not a bug.

Where the "isTotal" confusion comes from

There's no single official source of an isTotal field, so the name almost certainly comes from one of these:

1. Memory or autocomplete drift. totalCount gets misremembered as isTotal, especially since many GitHub GraphQL booleans genuinely start with is (isPrivate, isFork, isArchived, isDraft). The brain pattern-matches "there's a total, and fields start with is."
2. Confusing a count with a boolean. is* fields in GitHub's schema return Boolean!. A total is a number, so it was never going to be an is* field. If you actually want a yes/no flag, is... names are right — just not for counts.
3. Cross-API bleed. Other REST or GraphQL APIs, pagination libraries, or internal wrappers sometimes expose a boolean like isTotal / is_total to signal "this is the grand total row." GitHub's API has no such concept.
4. LLM or codegen hallucination. Generated code occasionally invents plausible-sounding field names. isTotal is exactly the kind of name that sounds real but isn't.

Whatever the origin, the fix is the same: use totalCount (or the search-specific *Count fields).

GitHub GraphQL has no versioned endpoints

A common follow-up: "Maybe isTotal existed in an older API version and was removed?" It didn't, and here's why that framing doesn't apply. GitHub's GraphQL API is a single, continuously evolving schema served from api.github.com/graphql. It's sometimes called "v4," but there are no numbered endpoints you can pin to. Instead of breaking changes across versions, GitHub deprecates fields in place: a field gets a deprecation notice and a removal date, but the name stays queryable during the window.

That matters for two reasons. First, if isTotal had ever shipped, it would appear in the schema's deprecation history — it doesn't. Second, it means you can't "downgrade" to a version where a nonexistent field works. The schema you introspect today is the schema, period.

How to verify any GitHub GraphQL field yourself

Never guess a field name again. GraphQL is introspective, so the API can describe itself. There are three fast, authoritative ways to check.

1. Use the Explorer. Open the GitHub GraphQL Explorer (an in-browser GraphiQL instance). Start typing inside a connection and autocomplete lists the valid fields — you'll see totalCount, never isTotal.
2. Read the reference docs. The GraphQL objects reference is generated directly from the live schema, so it's always current. Search the page for your type (e.g. IssueConnection).
3. Grep the published schema. Download the IDL and search it locally:

# Grab the auto-generated public schema and search for a field 
curl -sL raw.githubusercontent.com/octokit/graphql-schema/master/schema.graphql \   | grep -i "istotal"      # returns nothing  curl -sL raw.githubusercontent.com/octokit/graphql-schema/master/schema.graphql \   | grep -c "totalCount"   # returns 147 (as of 2026-07-14)

The octokit/graphql-schema repository is auto-updated from the live API and is the same schema GitHub publishes for download and introspection. If a field isn't in there, it isn't in the API.

Volatile-fact note (as of 2026-07-14 UTC): the totalCount occurrence count (147) and the exact set of search *Count fields can change as GitHub evolves the schema. The absence of isTotal and the existence of totalCount are stable facts, but re-run the grep above or check the reference docs if you need the current numbers.

Quick reference: count fields at a glance

• Any standard connection → totalCount: Int!
• search(...) connection → repositoryCount, issueCount, userCount, discussionCount, codeCount, wikiCount (each Int!, results capped at 1,000)
• isTotal → does not exist; will raise a validation error
• Fetching a count only → request totalCount with no nodes/edges (and first: 0 for search) to keep the query cheap

Conclusion

The short version bears repeating: the GitHub GraphQL API isTotal field is a myth. No release ever shipped it, and because GitHub uses one evolving schema with in-place deprecations rather than versioned endpoints, there's no historical version to fall back to. What you actually want is totalCount on connection types — or, for search, the type-specific issueCount, repositoryCount, and friends. When in doubt, let the API tell you the truth: use the Explorer's autocomplete, read the auto-generated objects reference, or grep the public schema. Introspection is the one habit that turns "does this field exist?" from a guess into a five-second check. Update your query to totalCount, re-run it, and you're done.

References

• GitHub Docs — GraphQL objects reference (totalCount, connection types): https://docs.github.com/en/graphql/reference/objects
• GitHub Docs — Public schema (download & introspection): https://docs.github.com/en/graphql/overview/public-schema
• GitHub Docs — Introduction to GraphQL (introspection, __schema): https://docs.github.com/en/graphql/guides/introduction-to-graphql
• GitHub Docs — About the GraphQL API (single evolving schema, deprecations): https://docs.github.com/en/graphql/overview/about-the-graphql-api
• octokit/graphql-schema — auto-updated GitHub GraphQL schema (source used to verify field names): https://github.com/octokit/graphql-schema