GitLab · groups API · list a group's projects · Checked October 24, 2026

GitLab: 404 "Group Not Found" when listing a group's projects

A group's projects come from GET /groups/:id/projects, where :id is the group's number or its full path. GitLab looks the group up, then checks that your account may see it, and answers both failures the same way: a group that does not exist and a group you may not see cannot be told apart. All of the following was checked on October 24, 2026 in GitLab's source (lib/api/groups.rb, lib/api/helpers.rb, lib/gitlab/resource_lookup.rb, app/policies/group_policy.rb), in its documentation, and in GitLab.com's answers.

HTTP/1.1 404 Not Found

{"message":"404 Group Not Found"}

When GitLab answers "404 Group Not Found"

No group has that path or number: a typo, or the right name under the wrong parent group.
Your account may not see the group. A public group is visible to everyone, an internal group to every signed-in user except external users, and a private group to its members and to the members of one of its projects. Without a token you are anonymous, so an internal or private group answers 404, not 401.
It is a user's personal namespace, the name in gitlab.com/name/project. The groups API finds only groups; that user's projects come from GET /users/:id/projects.
The group was renamed or moved. GitLab's API looks a group up without following its old path, unlike a project: a project's old path still answers reads (301 to its number), but a group's old path answers 404 Group Not Found. The web pages and Git remotes do redirect, as long as no one has claimed the old path, so a clone made before the rename keeps working with the old group in its remote.

"404 Not Found" instead

A subgroup's path has a /, which the API needs as %2F: /groups/parent%2Fchild/projects. Sent as it is, the request matches no endpoint and GitLab answers {"error":"404 Not Found"}, without the word Group. A proxy in front of GitLab that decodes %2F causes the same answer.

A 200 that leaves projects out

Projects in subgroups are left out unless you add include_subgroups=true.
Projects of other groups shared with this group are included, unless you add with_shared=false.
Only projects your account may see are listed; without a token, only public ones, with fewer fields.
20 projects come per page by default, 100 at most (per_page); the rest are on the next pages.

What to do

Open the group's page in the browser, signed in as the token's account. If it shows, check the path, send / as %2F, or use the group's number.
If the browser lands on another address, the group was renamed: use the new path, and update your remote with git remote set-url.
If the address is a user's, list that user's projects with GET /users/:id/projects.
If the page does not show, ask a member of the group for access, or use a token from an account that has it.
429: wait the seconds that Retry-After gives, then ask again.

GitLab pipelines of a group in IntelliJ IDEA

Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of the GitLab projects in the IDE project, or, under Their groups, of the most recently active projects of their groups, subgroups included. It sends a subgroup's path encoded. For a project in a personal namespace, which has no group list, Their groups shows the project itself. From version 1.0.18, when the group was renamed or the project moved to another group since the clone, it lists that group under its new name; before, it showed only the project itself. When GitLab's limit is reached, it says to wait a minute (from version 1.0.21, when GitLab asks for longer, the time it opens again), and without a token, also that a personal access token can be added (reading stays free). Reading is free; retrying, cancelling and running are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.