How can I resolve a 404 error when accessing a GitLab repository in n8n on Docker?

Below are some steps to troubleshoot the “404 Not Found” error when retrieving a GitLab repository from n8n:

1. Verify the GitLab Server URL

Make sure the GitLab Server URL in your credential settings is correct. For example, if your GitLab instance is behind a reverse proxy, check that the URL (and port, if applicable) is the one the API expects. Also, ensure there’s no trailing slash as the credentials expect a format like:

https://your.gitlab.server

2. Double-Check Repository Identifier

When using the “Get Repository” operation, ensure that you are using the correct project identifier. GitLab’s API typically expects either the numeric project ID or a URL-encoded namespace/project name. If you mistakenly provide a wrong or non-existent identifier, GitLab will return a 404 error.

3. Confirm API Access and Token Scopes

Both Access Token and OAuth2 methods can be used, but it’s important that the token has sufficient permissions. For retrieving repository details, ensure that the token has at least the "api" scope enabled.

• If you’re using the API access token, review the token’s scopes in your GitLab account settings.

4. Test the API Outside of n8n

To isolate the issue, try calling the same GitLab API endpoint (such as /api/v4/projects/<your-project-id>) directly using a tool like cURL or Postman. For example:

BASHCopied
curl --header "Private-Token: YOUR_ACCESS_TOKEN" "https://your.gitlab.server/api/v4/projects/your-project-id"

If the request fails outside n8n, the issue is likely with the identifier or your GitLab instance’s configuration.

5. Check Reverse Proxy and Networking Configuration

Since your GitLab instance is behind an NGINX reverse proxy with websockets enabled, verify the proxy configuration to ensure it correctly forwards API calls. Incorrect rewrites or missing headers could cause the API call to reach an unexpected endpoint. Also, ensure that the reverse proxy isn’t inadvertently modifying the request URL.

6. Inspect n8n Logs

Review the n8n logs for any additional error details. Look for any clues that could indicate misconfigurations when forming the API request through the node. The logs might offer hints about what part of the request is being misinterpreted.

By following these steps, you should be able to pinpoint whether the 404 error originates from an incorrect endpoint, the provided project identifier, or potential networking/reverse proxy issues.
If after these checks the error still persists, consider testing with a simple API request using the same credentials to narrow down where the discrepancy occurs.