Ошибка 422 гитлаб

type	stage	group	info
reference	Manage	Authentication and Authorization	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Troubleshooting SAML (FREE)

This page contains possible solutions for problems you might encounter when using:

• SAML SSO for GitLab.com groups.
• The self-managed instance-level SAML OmniAuth Provider.

SAML debugging tools

SAML responses are base64 encoded, so we recommend the following browser plugins to decode them on the fly:

• SAML-tracer for Firefox.
• SAML Message Decoder for Chrome.

Pay specific attention to:

• The NameID, which we use to identify which user is signing in. If the user has previously signed in, this
  must match the value we have stored.
• The presence of a X509Certificate, which we require to verify the response signature.
• The SubjectConfirmation and Conditions, which can cause errors if misconfigured.

Generate a SAML response

Use SAML responses to preview the attribute names and values sent in the assertions list while attempting to sign in
using an identity provider.

To generate a SAML Response:

1. Install one of the browser debugging tools.
2. Open a new browser tab.
3. Open the SAML tracer console:
   • Chrome: On a context menu on the page, select Inspect, then select the SAML tab in the opened developer
     console.
   • Firefox: Select the SAML-tracer icon located on the browser toolbar.
4. Go to the GitLab single sign-on URL for the group in the same browser tab with the SAML tracer open.
5. Select Authorize or attempt to sign in. A SAML response is displayed in the tracer console that resembles this
   example SAML response.
6. Within the SAML tracer, select the Export icon to save the response in JSON format.

Testing GitLab SAML

You can use one of the following to troubleshoot SAML:

• A complete GitLab with SAML testing environment using Docker compose.
• A quick start guide to start a Docker container
  with a plug and play SAML 2.0 identity provider if you only require a SAML provider.
• A local environment by
  enabling SAML for groups on a self-managed instance.

Verify configuration

For convenience, we’ve included some example resources used by our Support Team. While they may help you verify the SAML app configuration, they are not guaranteed to reflect the current state of third-party products.

Calculate the fingerprint

If you use a idp_cert_fingerprint, it must be a SHA1 fingerprint. To calculate a SHA1 fingerprint, download the certificate file and run:

openssl x509 -in <filename.crt> -noout -fingerprint -sha1

Replace filename.crt with the name of the certificate file.

Searching Rails log for a SAML response (FREE SELF)

You can find the base64-encoded SAML Response in the production_json.log.
This response is sent from the identity provider, and contains user information that is consumed by GitLab.
Many errors in the SAML integration can be solved by decoding this response and comparing it to the SAML settings in the GitLab configuration file.

For example, with SAML for groups,
you should be able to find the base64 encoded SAML response by searching with the following filters:

• json.meta.caller_id: Groups::OmniauthCallbacksController#group_saml
• json.meta.user or json.username: username
• json.method: POST
• json.path: /groups/GROUP-PATH/-/saml/callback

In a relevant log entry, the json.params should provide a valid response with:

• "key": "SAMLResponse" and the "value": (full SAML response),
• "key": "RelayState" with "value": "/group-path", and
• "key": "group_id" with "value": "group-path".

You should also check the decoded SAML response with the following filters
in case the customer has configured SAML Group Sync:

• json.class: GroupSamlGroupSyncWorker
• json.args: <user ID> or <group ID>

In the relevant log entry, the:

• json.args are in the form <userID>, <group ID>, [group link ID 1, group link ID 2, ..., group link ID N].
• json.extra.group_saml_group_sync_worker.stats.* fields show how many times
  this run of group sync added, removed or changed the user’s membership.

In some cases, if the SAML response is lengthy, you may receive a "key": "truncated" with "value":"...".
In these cases, use one of the SAML debugging tools, or for SAML SSO for groups,
a group owner can get a copy of the SAML response from when they select
the «Verify SAML Configuration» button on the group SSO Settings page.

Use a base64 decoder to see a human-readable version of the SAML response. To avoid pasting the SAML response online to decode it, you can use your
browser’s console in the developers tools:

atob(decodeURI("<paste_SAML_response_here>"))

You should get the SAML response in XML format as output.

Configuration errors

Invalid audience

This error means that the identity provider doesn’t recognize GitLab as a valid sender and
receiver of SAML requests. Make sure to:

• Add the GitLab callback URL to the approved audiences of the identity provider server.
• Avoid trailing whitespace in the issuer string.

Key validation error, Digest mismatch or Fingerprint mismatch

These errors all come from a similar place, the SAML certificate. SAML requests
must be validated using either a fingerprint, a certificate, or a validator.

For this requirement, be sure to take the following into account:

• If you use a fingerprint, it must be the correct SHA1 fingerprint. To confirm that you are using
  the correct SHA1 fingerprint:
  1. Re-download the certificate file.
  2. Calculate the fingerprint.
  3. Compare the fingerprint to the value provided in idp_cert_fingerprint. The values should be the same.
• If no certificate is provided in the settings, a fingerprint or fingerprint
  validator needs to be provided and the response from the server must contain
  a certificate (<ds:KeyInfo><ds:X509Data><ds:X509Certificate>).
• If a certificate is provided in the settings, it is no longer necessary for
  the request to contain one. In this case the fingerprint or fingerprint
  validators are optional.

If none of the above described scenarios is valid, the request
fails with one of the mentioned errors.

Missing claims, or Email can't be blank errors

The identity provider server needs to pass certain information in order for GitLab to either
create an account, or match the login information to an existing account. email
is the minimum amount of information that needs to be passed. If the identity provider server
is not providing this information, all SAML requests fail.

Make sure this information is provided.

Another issue that can result in this error is when the correct information is being sent by
the identity provider, but the attributes don’t match the names in the OmniAuth info hash. In this case,
you must set attribute_statements in the SAML configuration to
map the attribute names in your SAML Response to the corresponding OmniAuth info hash names.

User sign in banner error messages

Message: «SAML authentication failed: Extern UID has already been taken»

This error suggests you are signed in as a GitLab user but have already linked your SAML identity to a different GitLab user. Sign out and then try to sign in again using SAML, which should log you into GitLab with the linked user account.

If you do not wish to use that GitLab user with the SAML login, you can unlink the GitLab account from the SAML app.

Message: «SAML authentication failed: User has already been taken»

The user that you’re signed in with already has SAML linked to a different identity, or the NameID value has changed.
Here are possible causes and solutions:

Cause	Solution
You’ve tried to link multiple SAML identities to the same user, for a given identity provider.	Change the identity that you sign in with. To do so, unlink the previous SAML identity from this GitLab account before attempting to sign in again.
The NameID changes every time the user requests SSO identification	Check the NameID is not set with Transient format, or the NameID is not changing on subsequent requests.

Message: «SAML authentication failed: Email has already been taken»

Cause	Solution
When a user account with the email address already exists in GitLab, but the user does not have the SAML identity tied to their account.	The user needs to link their account.

User accounts are created in one of the following ways:

• User registration
• Sign in through OAuth
• Sign in through SAML
• SCIM provisioning

Message: «SAML authentication failed: Extern UID has already been taken, User has already been taken»

Getting both of these errors at the same time suggests the NameID capitalization provided by the identity provider didn’t exactly match the previous value for that user.

This can be prevented by configuring the NameID to return a consistent value. Fixing this for an individual user involves changing the identifier for the user. For GitLab.com, the user needs to unlink their SAML from the GitLab account.

Message: «Request to link SAML account must be authorized»

Ensure that the user who is trying to link their GitLab account has been added as a user within the identity provider’s SAML app.

Alternatively, the SAML response may be missing the InResponseTo attribute in the
samlp:Response tag, which is expected by the SAML gem.
The identity provider administrator should ensure that the login is
initiated by the service provider and not only the identity provider.

Message: «There is already a GitLab account associated with this email address. Sign in with your existing credentials to connect your organization’s account» (PREMIUM SAAS)

A user can see this message when they are trying to manually link SAML to their existing GitLab.com account.

To resolve this problem, the user should check they are using the correct GitLab password to sign in. The user first needs
to reset their password if both:

• The account was provisioned by SCIM.
• They are signing in with username and password for the first time.

Other user sign in issues

Verify NameID

In troubleshooting, any authenticated user can use the API to verify the NameID GitLab already has linked to their user by visiting https://gitlab.com/api/v4/user and checking the extern_uid under identities.

For self-managed, administrators can use the users API to see the same information.

When using SAML for groups, group members of a role with the appropriate permissions can make use of the members API to view group SAML identity information for members of the group.

This can then be compared to the NameID being sent by the identity provider by decoding the message with a SAML debugging tool. We require that these match to identify users.

Stuck in a login «loop»

Ensure that the GitLab single sign-on URL (for GitLab.com) or the instance URL (for self-managed) has been configured as «Login URL» (or similarly named field) in the identity provider’s SAML app.

For GitLab.com, alternatively, when users need to link SAML to their existing GitLab.com account, provide the GitLab single sign-on URL and instruct users not to use the SAML app on first sign in.

Users receive a 404 (PREMIUM SAAS)

Because SAML SSO for groups is a paid feature, your subscription expiring can result in a 404 error when you’re signing in using SAML SSO on GitLab.com.
If all users are receiving a 404 when attempting to sign in using SAML, confirm
there is an active subscription being used in this SAML SSO namespace.

If you receive a 404 during setup when using «verify configuration», make sure you have used the correct
SHA-1 generated fingerprint.

If a user is trying to sign in for the first time and the GitLab single sign-on URL has not been configured, they may see a 404.
As outlined in the user access section, a group Owner needs to provide the URL to users.

If all users are receiving a 404 after signing in to the identity provider (IdP):

• Verify the assertion_consumer_service_url:

  • In the GitLab configuration by matching it to the HTTPS endpoint of GitLab.
  • As the Assertion Consumer Service URL or equivalent when setting up the SAML app on your IdP.

• Verify if the 404 is related to the user having too many groups assigned to them in their Azure IdP by checking:

  • If the user has group links configured.
  • Audit events if the user gets added to the group and then immediately removed.

For configuration examples for some of the common providers, see the example group SAML and SCIM configurations.

500 error after login (FREE SELF)

If you see a «500 error» in GitLab when you are redirected back from the SAML
sign-in page, this could indicate that:

• GitLab couldn’t get the email address for the SAML user. Ensure the identity provider provides a claim containing the user’s
  email address using the claim name email or mail.
• The certificate set your gitlab.rb file for identity provider_cert_fingerprint or identity provider_cert file is incorrect.
• Your gitlab.rb file is set to enable identity provider_cert_fingerprint, and identity provider_cert is being provided, or the reverse.

422 error after login (FREE SELF)

If you see a «422 error» in GitLab when you are redirected from the SAML
sign-in page, you might have an incorrectly configured Assertion Consumer
Service (ACS) URL on the identity provider.

Make sure the ACS URL points to https://gitlab.example.com/users/auth/saml/callback, where
gitlab.example.com is the URL of your GitLab instance.

If the ACS URL is correct, and you still have errors, review the other
Troubleshooting sections.

User is blocked when signing in through SAML (FREE SELF)

The following are the most likely reasons that a user is blocked when signing in through SAML:

• In the configuration, gitlab_rails['omniauth_block_auto_created_users'] = true is set and this is the user’s first time signing in.
• required_groups are configured but the user is not a member of one.

Google workspace troubleshooting tips

The Google Workspace documentation on SAML app error messages is helpful for debugging if you are seeing an error from Google while signing in.
Pay particular attention to the following 403 errors:

• app_not_configured
• app_not_configured_for_user

SAML Name ID and email address do not match your user account (PREMIUM SAAS)

If users encounter the error SAML Name ID and email address do not match your user account. Contact an administrator.
this means:

• The NameID value sent by SAML does not match the existing SAML identity extern_uid value.
• Either the SAML response did not include an email address or the email address did not match the user’s GitLab email address.

A GitLab group Owner can use the SAML API to update the user’s SAML extern_uid.
The extern_uid value must match the Name ID value sent by the SAML identity provider (IdP). Depending on the IdP configuration
this may be a generated unique ID, an email address, or other value.

Message: «The member’s email address is not linked to a SAML account» (PREMIUM SAAS)

This error appears when you try to invite a user to a GitLab.com group (or subgroup or project within a group) that has SAML SSO enforcement enabled.

If you see this message after trying to invite a user to a group:

1. Ensure the user has been added to the SAML identity provider.
2. Ask the user to link SAML to their existing GitLab.com account, if they have one. Otherwise, ask the user to create a GitLab.com account by accessing GitLab.com through the identity provider’s dashboard, or by signing up manually and linking SAML to their new account.

I got into trouble after installing Gitlab on CentOs7. For the first time I was redirected to the admin password creation page and after the password for the admin user, the server sent error.

422
The change you requested was rejected.

I had set the url value based on the site guide.

Set the external_url in /etc/gitlab/gitlab.rb:

external_url "https://example.com/gitlab"

I checked the links below for similar situations. I didn’t find the right answer. My server was in the local area and had no internet access.

Error 422 after installing gitlab on Ubuntu 18.04

After Update Error: «422 The change you requested was rejected.»

Error 422 after installing Gitlab on Ubuntu 16.04

API Docs (FREE)

Use the GitLab APIs to automate GitLab.

You can also use a partial OpenAPI definition,
to test the API directly from the GitLab user interface.
Contributions are welcome.

REST API

A REST API is available in GitLab.
Usage instructions are below.
For a list of the available resources and their endpoints, see
REST API resources.

For an introduction and basic steps, see
How to make GitLab API calls.

SCIM API (PREMIUM SAAS)

GitLab provides an SCIM API that both implements
the RFC7644 protocol and provides the
/Users endpoint. The base URL is /api/scim/v2/groups/:group_path/Users/.

GraphQL API

A GraphQL API is available in GitLab.

With GraphQL, you can make an API request for only what you need,
and it’s versioned by default.

GraphQL co-exists with the current v4 REST API. If we have a v5 API, this should
be a compatibility layer on top of GraphQL.

There were some patenting and licensing concerns with GraphQL. However, these
have been resolved to our satisfaction. The reference implementations
were re-licensed under MIT, and the OWF license used for the GraphQL specification.

When GraphQL is fully implemented, GitLab:

• Can delete controller-specific endpoints.
• Will no longer maintain two different APIs.

Compatibility guidelines

The HTTP API is versioned with a single number, which is currently 4. This number
symbolizes the major version number, as described by SemVer.
Because of this, backward-incompatible changes require this version number to
change.

The minor version isn’t explicit, which allows for a stable API
endpoint. New features can be added to the API in the same
version number.

New features and bug fixes are released in tandem with GitLab. Apart
from incidental patch and security releases, GitLab is released on the 22nd of each
month. Major API version changes, and removal of entire API versions, are done in tandem
with major GitLab releases.

All deprecations and changes between versions are in the documentation.
For the changes between v3 and v4, see the v3 to v4 documentation.

Current status

Only API version v4 is available. Version v3 was removed in
GitLab 11.0.

How to use the API

API requests must include both api and the API version. The API
version is defined in lib/api.rb.
For example, the root of the v4 API is at /api/v4.

Valid API request

If you have a GitLab instance at gitlab.example.com:

curl "https://gitlab.example.com/api/v4/projects"

The API uses JSON to serialize data. You don’t need to specify .json at the
end of the API URL.

API request to expose HTTP response headers

If you want to expose HTTP response headers, use the --include option:

curl --include "https://gitlab.example.com/api/v4/projects"
HTTP/2 200
...

This request can help you investigate an unexpected response.

API request that includes the exit code

If you want to expose the HTTP exit code, include the --fail option:

curl --fail "https://gitlab.example.com/api/v4/does-not-exist"
curl: (22) The requested URL returned error: 404

The HTTP exit code can help you diagnose the success or failure of your REST request.

Authentication

Most API requests require authentication, or only return public data when
authentication isn’t provided. When authentication is not required, the documentation
for each endpoint specifies this. For example, the
/projects/:id endpoint does not require authentication.

There are several ways you can authenticate with the GitLab API:

• OAuth2 tokens
• Personal access tokens
• Project access tokens
• Session cookie
• GitLab CI/CD job token (Specific endpoints only)

Project access tokens are supported by:

• Self-managed GitLab Free and higher.
• GitLab SaaS Premium and higher.

If you are an administrator, you or your application can authenticate as a specific user.
To do so, use:

• Impersonation tokens
• Sudo

If authentication information is not valid or is missing, GitLab returns an error
message with a status code of 401:

{
  "message": "401 Unauthorized"
}

OAuth2 tokens

You can use an OAuth2 token to authenticate with the API by passing
it in either the access_token parameter or the Authorization header.

Example of using the OAuth2 token in a parameter:

curl "https://gitlab.example.com/api/v4/projects?access_token=OAUTH-TOKEN"

Example of using the OAuth2 token in a header:

curl --header "Authorization: Bearer OAUTH-TOKEN" "https://gitlab.example.com/api/v4/projects"

Read more about GitLab as an OAuth2 provider.

NOTE:
We recommend OAuth access tokens have an expiration. You can use the refresh_token parameter
to refresh tokens. Integrations may need to be updated to use refresh tokens prior to
expiration, which is based on the expires_in
property in the token endpoint response. See OAuth2 token documentation
for examples requesting a new access token using a refresh token.

A default refresh setting of two hours is tracked in this issue.

Personal/project access tokens

You can use access tokens to authenticate with the API by passing it in either
the private_token parameter or the PRIVATE-TOKEN header.

Example of using the personal or project access token in a parameter:

curl "https://gitlab.example.com/api/v4/projects?private_token=<your_access_token>"

Example of using the personal or project access token in a header:

curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects"

You can also use personal or project access tokens with OAuth-compliant headers:

curl --header "Authorization: Bearer <your_access_token>" "https://gitlab.example.com/api/v4/projects"

Session cookie

Signing in to the main GitLab application sets a _gitlab_session cookie. The
API uses this cookie for authentication if it’s present. Using the API to
generate a new session cookie isn’t supported.

The primary user of this authentication method is the web frontend of GitLab
itself. The web frontend can use the API as the authenticated user to get a
list of projects without explicitly passing an access token.

GitLab CI/CD job token

When a pipeline job is about to run, GitLab generates a unique token and injects it as the
CI_JOB_TOKEN predefined variable.

You can use a GitLab CI/CD job token to authenticate with specific API endpoints:

• Packages:
  • Package Registry. To push to the
    Package Registry, you can use deploy tokens.
  • Container Registry
    (the $CI_REGISTRY_PASSWORD is $CI_JOB_TOKEN).
  • Container Registry API (scoped to the job’s project, when the ci_job_token_scope feature flag is enabled)
• Get job artifacts.
• Get job token’s job.
• Pipeline triggers, using the token= parameter.
• Release creation.
• Terraform plan.

The token has the same permissions to access the API as the user that triggers the
pipeline. Therefore, this user must be assigned to a role that has the required privileges.

The token is valid only while the pipeline job runs. After the job finishes, you can’t
use the token anymore.

A job token can access a project’s resources without any configuration, but it might
give extra permissions that aren’t necessary. There is a proposal
to redesign the feature for more strategic control of the access permissions.

GitLab CI/CD job token security

To make sure that this token doesn’t leak, GitLab:

• Masks the job token in job logs.
• Grants permissions to the job token only when the job is running.

To make sure that this token doesn’t leak, you should also configure
your runners to be secure. Avoid:

• Using Docker’s privileged mode if the machines are re-used.
• Using the shell executor when jobs
  run on the same machine.

If you have an insecure GitLab Runner configuration, you increase the risk that someone
tries to steal tokens from other jobs.

Limit GitLab CI/CD job token access

• Introduced in GitLab 14.1.
• Deployed behind a feature flag, disabled by default.
• Disabled on GitLab.com.
• Not recommended for production use.
• To use in GitLab self-managed instances, ask a GitLab administrator to enable it. (FREE SELF)

This in-development feature might not be available for your use. There can be
risks when enabling features still in development.
Refer to this feature’s version history for more details.

You can limit the access scope of a project’s CI/CD job token to increase the
job token’s security. A job token might give extra permissions that aren’t necessary
to access specific private resources. Limiting the job token access scope reduces the risk of a leaked
token being used to access private data that the user associated to the job can access.

Control the job token access scope with an allowlist of other projects authorized
to be accessed by authenticating with the current project’s job token. By default
the token scope only allows access to the same project where the token comes from.
Other projects can be added and removed by maintainers with access to both projects.

This setting is enabled by default for all new projects, and disabled by default in projects
created before GitLab 14.1. It is strongly recommended that project maintainers enable this
setting at all times, and configure the allowlist for cross-project access if needed.

For example, when the setting is enabled, jobs in a pipeline in project A have
a CI_JOB_TOKEN scope limited to project A. If the job needs to use the token
to make an API request to a private project B, then B must be added to the allowlist for A.
If project B is public or internal, it doesn’t need to be added to the allowlist.
The job token scope is only for controlling access to private projects.

To enable and configure the job token scope limit:

1. On the top bar, select Menu > Projects and find your project.
2. On the left sidebar, select Settings > CI/CD.
3. Expand Token Access.
4. Toggle Limit CI_JOB_TOKEN access to enabled.
5. (Optional) Add existing projects to the token’s access scope. The user adding a
   project must have the maintainer role in both projects.

If the job token scope limit is disabled, the token can potentially be used to authenticate
API requests to all projects accessible to the user that triggered the job.

There is a proposal to improve
the feature with more strategic control of the access permissions.

Enable or disable CI job token scope limit (FREE SELF)

The GitLab CI/CD job token access scope limit is under development and not ready for production
use. It is deployed behind a feature flag that is disabled by default.
GitLab administrators with access to the GitLab Rails console
can enable it.

To enable it:

Feature.enable(:ci_scoped_job_token)

To disable it:

Feature.disable(:ci_scoped_job_token)

Impersonation tokens

Impersonation tokens are a type of personal access token.
They can be created only by an administrator, and are used to authenticate with the
API as a specific user.

Use impersonation tokens an alternative to:

• The user’s password or one of their personal access tokens.
• The Sudo feature. The user’s or administrator’s password or token
  may not be known, or may change over time.

For more information, see the users API
documentation.

Impersonation tokens are used exactly like regular personal access tokens, and
can be passed in either the private_token parameter or the PRIVATE-TOKEN
header.

Disable impersonation

Introduced in GitLab 11.6.

By default, impersonation is enabled. To disable impersonation:

For Omnibus installations

1. Edit the /etc/gitlab/gitlab.rb file:

   gitlab_rails['impersonation_enabled'] = false

2. Save the file, and then reconfigure
   GitLab for the changes to take effect.

To re-enable impersonation, remove this configuration, and then reconfigure
GitLab.

For installations from source

1. Edit the config/gitlab.yml file:

   gitlab:
     impersonation_enabled: false

2. Save the file, and then restart
   GitLab for the changes to take effect.

To re-enable impersonation, remove this configuration, and then restart GitLab.

Sudo

All API requests support performing an API request as if you were another user,
provided you’re authenticated as an administrator with an OAuth or personal
access token that has the sudo scope. The API requests are executed with the
permissions of the impersonated user.

As an administrator, pass the sudo parameter either
by using query string or a header with an ID or username (case insensitive) of
the user you want to perform the operation as. If passed as a header, the header
name must be Sudo.

If a non administrative access token is provided, GitLab returns an error
message with a status code of 403:

{
  "message": "403 Forbidden - Must be admin to use sudo"
}

If an access token without the sudo scope is provided, an error message is
be returned with a status code of 403:

{
  "error": "insufficient_scope",
  "error_description": "The request requires higher privileges than provided by the access token.",
  "scope": "sudo"
}

If the sudo user ID or username cannot be found, an error message is
returned with a status code of 404:

{
  "message": "404 User with ID or username '123' Not Found"
}

Example of a valid API request and a request using cURL with sudo request,
providing a username:

GET /projects?private_token=<your_access_token>&sudo=username

curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Sudo: username" "https://gitlab.example.com/api/v4/projects"

Example of a valid API request and a request using cURL with sudo request,
providing an ID:

GET /projects?private_token=<your_access_token>&sudo=23

curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Sudo: 23" "https://gitlab.example.com/api/v4/projects"

Status codes

The API is designed to return different status codes according to context and
action. This way, if a request results in an error, you can get
insight into what went wrong.

The following table gives an overview of how the API functions generally behave.

Request type	Description
GET	Access one or more resources and return the result as JSON.
POST	Return 201 Created if the resource is successfully created and return the newly created resource as JSON.
GET / PUT	Return 200 OK if the resource is accessed or modified successfully. The (modified) result is returned as JSON.
DELETE	Returns 204 No Content if the resource was deleted successfully.

The following table shows the possible return codes for API requests.

Return values	Description
200 OK	The GET, PUT or DELETE request was successful, and the resource(s) itself is returned as JSON.
204 No Content	The server has successfully fulfilled the request, and there is no additional content to send in the response payload body.
201 Created	The POST request was successful, and the resource is returned as JSON.
304 Not Modified	The resource hasn’t been modified since the last request.
400 Bad Request	A required attribute of the API request is missing. For example, the title of an issue is not given.
401 Unauthorized	The user isn’t authenticated. A valid user token is necessary.
403 Forbidden	The request isn’t allowed. For example, the user isn’t allowed to delete a project.
404 Not Found	A resource couldn’t be accessed. For example, an ID for a resource couldn’t be found.
405 Method Not Allowed	The request isn’t supported.
409 Conflict	A conflicting resource already exists. For example, creating a project with a name that already exists.
412	The request was denied. This can happen if the If-Unmodified-Since header is provided when trying to delete a resource, which was modified in between.
422 Unprocessable	The entity couldn’t be processed.
429 Too Many Requests	The user exceeded the application rate limits.
500 Server Error	While handling the request, something went wrong on the server.

Pagination

GitLab supports the following pagination methods:

• Offset-based pagination. This is the default method and is available on all endpoints.
• Keyset-based pagination. Added to selected endpoints but being
  progressively rolled out.

For large collections, for performance reasons we recommend keyset pagination
(when available) instead of offset pagination.

Offset-based pagination

Sometimes, the returned result spans many pages. When listing resources, you can
pass the following parameters:

Parameter	Description
page	Page number (default: 1).
per_page	Number of items to list per page (default: 20, max: 100).

In the following example, we list 50 namespaces per page:

curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/namespaces?per_page=50"

Pagination Link header

Link headers are returned with each
response. They have rel set to prev, next, first, or last and contain
the relevant URL. Be sure to use these links instead of generating your own URLs.

For GitLab.com users, some pagination headers may not be returned.

In the following cURL example, we limit the output to three items per page
(per_page=3) and we request the second page (page=2) of comments
of the issue with ID 8 which belongs to the project with ID 9:

curl --head --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/9/issues/8/notes?per_page=3&page=2"

The response is:

HTTP/2 200 OK
cache-control: no-cache
content-length: 1103
content-type: application/json
date: Mon, 18 Jan 2016 09:43:18 GMT
link: <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=1&per_page=3>; rel="prev", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=3&per_page=3>; rel="next", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=1&per_page=3>; rel="first", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=3&per_page=3>; rel="last"
status: 200 OK
vary: Origin
x-next-page: 3
x-page: 2
x-per-page: 3
x-prev-page: 1
x-request-id: 732ad4ee-9870-4866-a199-a9db0cde3c86
x-runtime: 0.108688
x-total: 8
x-total-pages: 3

Other pagination headers

GitLab also returns the following additional pagination headers:

Header	Description
x-next-page	The index of the next page.
x-page	The index of the current page (starting at 1).
x-per-page	The number of items per page.
X-prev-page	The index of the previous page.
x-total	The total number of items.
x-total-pages	The total number of pages.

For GitLab.com users, some pagination headers may not be returned.

Keyset-based pagination

Keyset-pagination allows for more efficient retrieval of pages and — in contrast
to offset-based pagination — runtime is independent of the size of the
collection.

This method is controlled by the following parameters:

Parameter	Description
pagination	keyset (to enable keyset pagination).
per_page	Number of items to list per page (default: 20, max: 100).

In the following example, we list 50 projects per page, ordered
by id ascending.

curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc"

The response header includes a link to the next page. For example:

HTTP/1.1 200 OK
...
Links: <https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc&id_after=42>; rel="next"
Link: <https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc&id_after=42>; rel="next"
Status: 200 OK
...

WARNING:
The Links header is scheduled to be removed in GitLab 14.0 to be aligned with the
W3C Link specification. The Link
header was added in GitLab 13.1
and should be used instead.

The link to the next page contains an additional filter id_after=42 that
excludes already-retrieved records. The type of filter depends on the
order_by option used, and we may have more than one additional filter.

When the end of the collection is reached and there are no additional
records to retrieve, the Link header is absent and the resulting array is
empty.

We recommend using only the given link to retrieve the next page instead of
building your own URL. Apart from the headers shown, we don’t expose additional
pagination headers.

Keyset-based pagination is supported only for selected resources and ordering
options:

Resource	Order
Projects	order_by=id only.

Path parameters

If an endpoint has path parameters, the documentation displays them with a
preceding colon.

For example:

DELETE /projects/:id/share/:group_id

The :id path parameter needs to be replaced with the project ID, and the
:group_id needs to be replaced with the ID of the group. The colons :
shouldn’t be included.

The resulting cURL request for a project with ID 5 and a group ID of 17 is then:

curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/share/17"

Path parameters that are required to be URL-encoded must be followed. If not,
it doesn’t match an API endpoint and responds with a 404. If there’s
something in front of the API (for example, Apache), ensure that it doesn’t decode
the URL-encoded path parameters.

Namespaced path encoding

If using namespaced API requests, make sure that the NAMESPACE/PROJECT_PATH is
URL-encoded.

For example, / is represented by %2F:

GET /api/v4/projects/diaspora%2Fdiaspora

A project’s path isn’t necessarily the same as its name. A project’s path is
found in the project’s URL or in the project’s settings, under
General > Advanced > Change path.

File path, branches, and tags name encoding

If a file path, branch or tag contains a /, make sure it is URL-encoded.

For example, / is represented by %2F:

GET /api/v4/projects/1/repository/files/src%2FREADME.md?ref=master
GET /api/v4/projects/1/branches/my%2Fbranch/commits
GET /api/v4/projects/1/repository/tags/my%2Ftag

Request Payload

API Requests can use parameters sent as query strings
or as a payload body.
GET requests usually send a query string, while PUT or POST requests usually
send the payload body:

• Query string:

  curl --request POST "https://gitlab/api/v4/projects?name=<example-name>&description=<example-description>"

• Request payload (JSON):

  curl --request POST --header "Content-Type: application/json" 
       --data '{"name":"<example-name>", "description":"<example-description"}' "https://gitlab/api/v4/projects"

URL encoded query strings have a length limitation. Requests that are too large
result in a 414 Request-URI Too Large error message. This can be resolved by
using a payload body instead.

Encoding API parameters of array and hash types

You can request the API with array and hash types parameters:

array

import_sources is a parameter of type array:

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" 
-d "import_sources[]=github" 
-d "import_sources[]=bitbucket" 
"https://gitlab.example.com/api/v4/some_endpoint"

hash

override_params is a parameter of type hash:

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" 
--form "namespace=email" 
--form "path=impapi" 
--form "file=@/path/to/somefile.txt"
--form "override_params[visibility]=private" 
--form "override_params[some_other_param]=some_value" 
"https://gitlab.example.com/api/v4/projects/import"

Array of hashes

variables is a parameter of type array containing hash key/value pairs
[{ 'key': 'UPLOAD_TO_S3', 'value': 'true' }]:

curl --globoff --request POST --header "PRIVATE-TOKEN: <your_access_token>" 
"https://gitlab.example.com/api/v4/projects/169/pipeline?ref=master&variables[][key]=VAR1&variables[][value]=hello&variables[][key]=VAR2&variables[][value]=world"

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" 
--header "Content-Type: application/json" 
--data '{ "ref": "master", "variables": [ {"key": "VAR1", "value": "hello"}, {"key": "VAR2", "value": "world"} ] }' 
"https://gitlab.example.com/api/v4/projects/169/pipeline"

id vs iid

Some resources have two similarly-named fields. For example, issues,
merge requests, and project milestones.
The fields are:

• id: ID that is unique across all projects.
• iid: Additional, internal ID (displayed in the web UI) that’s unique in the
  scope of a single project.

If a resource has both the iid field and the id field, the iid field is
usually used instead of id to fetch the resource.

For example, suppose a project with id: 42 has an issue with id: 46 and
iid: 5. In this case:

• A valid API request to retrieve the issue is GET /projects/42/issues/5.
• An invalid API request to retrieve the issue is GET /projects/42/issues/46.

Not all resources with the iid field are fetched by iid. For guidance
regarding which field to use, see the documentation for the specific resource.

Data validation and error reporting

When working with the API you may encounter validation errors, in which case
the API returns an HTTP 400 error.

Such errors appear in the following cases:

• A required attribute of the API request is missing (for example, the title of
  an issue isn’t given).
• An attribute did not pass the validation (for example, the user bio is too
  long).

When an attribute is missing, you receive something like:

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "message":"400 (Bad request) "title" not given"
}

When a validation error occurs, error messages are different. They hold
all details of validation errors:

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "message": {
        "bio": [
            "is too long (maximum is 255 characters)"
        ]
    }
}

This makes error messages more machine-readable. The format can be described as
follows:

{
    "message": {
        "<property-name>": [
            "<error-message>",
            "<error-message>",
            ...
        ],
        "<embed-entity>": {
            "<property-name>": [
                "<error-message>",
                "<error-message>",
                ...
            ],
        }
    }
}

Unknown route

When you attempt to access an API URL that doesn’t exist, you receive a
404 Not Found message.

HTTP/1.1 404 Not Found
Content-Type: application/json
{
    "error": "404 Not Found"
}

Encoding + in ISO 8601 dates

If you need to include a + in a query parameter, you may need to use %2B
instead, due to a W3 recommendation
that causes a + to be interpreted as a space. For example, in an ISO 8601 date,
you may want to include a specific time in ISO 8601 format, such as:

2017-10-17T23:11:13.000+05:30

The correct encoding for the query parameter would be:

2017-10-17T23:11:13.000%2B05:30

Clients

There are many unofficial GitLab API Clients for most of the popular programming
languages. For a complete list, visit the GitLab website.

Rate limits

For administrator documentation on rate limit settings, see
Rate limits. To find the settings that are
specifically used by GitLab.com, see
GitLab.com-specific rate limits.

Content type

The GitLab API supports the application/json content type by default, though
some API endpoints also support text/plain.

In GitLab 13.10 and later,
API endpoints do not support text/plain by default, unless it’s explicitly documented.