Dovkie
Sign in
Back to monitors

gitlab

GitLab API

REST
OpenAPI (YAML)
https://gitlab.com/gitlab-org/gitlab/-/raw/master/doc/api/openapi/openapi_v2.yaml
Informational AI classification

GitLab API docs improved with better summaries and descriptions

OpenAPI documentation for GitLab's issue-related endpoints received comprehensive updates to summary and description fields across multiple endpoints. Changes include added summary fields where missing, improved descriptions with clarification on authorization requirements and operation details, and standardized language across similar endpoints — all without modifying request/response schemas or endpoint behavior.

Alert history

  • Informational

    GitLab API docs improved with better summaries and descriptions

    OpenAPI documentation for GitLab's issue-related endpoints received comprehensive updates to summary and description fields across multiple endpoints. Changes include added summary fields where missing, improved descriptions with clarification on authorization requirements and operation details, and standardized language across similar endpoints — all without modifying request/response schemas or endpoint behavior.

  • Informational

    Update documentation and descriptions for member/package/avatar endpoints

    This diff updates OpenAPI documentation across multiple endpoints, rewording summaries and descriptions for clarity and accuracy. Changes include distinguishing between group and project member operations, clarifying that certain endpoints return only direct members or inherited members, and improving descriptions for group avatars, packages, and namespace subscriptions. No API behavior, request parameters, or response structures are altered—only documentation text is refined.

  • Additive

    Add optional ref_type query parameter to archive endpoint

    A new optional query parameter ref_type has been added to the archive endpoint, allowing callers to specify whether the sha refers to a branch (heads) or a tag (tags). This is purely additive and does not break existing integrations.

  • Informational

    OpenAPI spec int32 to int64 format corrections

    Multiple integer field formats updated from int32 to int64 across package, project, protected branch, and snippet schema definitions in the OpenAPI specification. This is a documentation correction reflecting actual API behavior and does not change runtime behavior or client compatibility.

  • Informational

    GitLab Conan API documentation improvements

    The diff updates summaries and descriptions for 15 Conan package registry endpoints to be more descriptive and precise. Changes include: replacing generic action verbs with specific operation names ("Ping the Conan API" → "Verify availability of a Conan repository"), removing "This feature was introduced in GitLab X.Y" boilerplate, and adding clearer operation context. No endpoint paths, parameters, response schemas, or behaviour are modified.

  • Informational

    OpenAPI spec documentation improvements

    This diff contains rewording and clarity improvements to OpenAPI documentation summaries and descriptions across multiple endpoints. The changes make descriptions more consistent and detailed (e.g., "Authenticate user against conan CLI" → "Retrieve an authentication token") but do not alter request/response schemas, parameters, or functional behavior.

  • Additive

    Add appearance_uploads metrics to GitLab Geo metrics

    Added 16 new optional response fields for appearance upload metrics to GitLab Geo API responses. These fields track checksum, synchronization, and verification status of appearance uploads across distributed instances. The change is purely additive and does not affect existing integrations.

  • Informational

    Update API documentation for invitations and topics endpoints

    Documentation clarifications across invitation management endpoints (groups/projects) and topic management endpoints. Updated summaries and descriptions to be more specific about endpoint behavior and to separate group-specific and project-specific operations that previously shared generic language. No changes to request/response schemas, parameters, or API behavior.

  • Informational

    Update GitLab API documentation descriptions for upload endpoints

    Updated descriptions for four file upload endpoints to clarify language and, in one case, to document required access roles. The changes reword "by ID/secret and filename" to "with a specified ID/secret and filename" and add role requirements for the /uploads/{secret}/{filename} GET endpoint. No endpoint URLs, request/response schemas, or functional behavior changed.

  • Informational

    Update API documentation summaries and descriptions

    GitLab has improved the OpenAPI documentation by rewriting numerous endpoint summaries and descriptions to be more consistent, concise, and descriptive of what the endpoint does. These changes include: NuGet package endpoints (v2, v3, and symbol uploads) now have clearer language about uploading packages; package management endpoints (list, retrieve, delete) use more consistent imperative language; project endpoints (get, delete, fork, archive) have improved summaries; and group/user listing endpoints have expanded descriptions with pagination and authentication details. No API behavior, parameters, or response schemas have changed — only the documentation strings that appear in API clients and tools.

  • Additive

    Add pagination method and keyset pagination support to commits list

    Added two new optional query parameters to the commits list endpoint: pagination (defaults to legacy, supports keyset option) and page_token (for keyset pagination). These are purely additive optional parameters that do not affect existing integrations using default pagination.

  • Informational

    Documentation improvements for usage_data and events endpoints

    Multiple API endpoint descriptions and summaries were clarified and expanded with additional implementation details. The changes improve documentation for the events list endpoint and several usage_data endpoints (track_events, metric_definitions, service_ping, track_event, non_sql_metrics, and queries), but do not alter any functional behaviour, parameters, or response structures.

  • Breaking

    New required field `uuid` added to CI JobRequest RunnerInfo response

    The uuid field (type string) has been added to API_Entities_Ci_JobRequest_RunnerInfo and marked as required. Any client or code generator that validates response payloads against this schema and previously operated without uuid will now see validation failures, making this a potentially breaking change for strict schema consumers. Clients that only read the fields they care about and ignore extras are unaffected.

  • Informational

    Clarify descriptions for wiki deletion and commit status endpoints

    GitLab API documentation was updated to clarify and improve descriptions for several endpoints: wiki deletion endpoints now say "from" instead of "for", commit status endpoints have more descriptive summaries and details about the functionality, and the web commits public key endpoint has a clearer description. These are documentation-only changes that do not alter request/response behavior or API structure.

  • Informational

    Documentation improvements for group/project endpoints

    Updated descriptions and summaries for multiple GitLab API endpoints to be more precise and descriptive. Changes include clarifying which endpoints apply to groups vs. projects (especially Debian distribution endpoints), improving response descriptions, and adding more complete operation summaries. No functional changes to request/response schema or endpoint behavior.

  • Additive

    Add project_topic_uploads metrics to geo status response

    The GitLab API response schema now includes 15 new optional fields for tracking project_topic_uploads synchronization and verification metrics in the geo status endpoint. These new fields follow the same pattern as existing project_repositories and project_uploads metrics and are purely additive—existing integrations remain unaffected.

  • Additive

    Add create_code_review_flow_consent field to group update

    A new optional boolean field create_code_review_flow_consent has been added to the group update schema. This field records explicit namespace consent for DAP-based Code Review routing and does not affect existing integrations.

  • Additive

    Add GCS HMAC configuration support to export API

    Added a new optional gcs_hmac_configuration object to the export API endpoints, enabling S3-interoperability HMAC key authentication for Google Cloud Storage. This provides an additional configuration option alongside existing AWS and S3 methods without breaking existing functionality.

  • Additive

    Add member_role_id field to project approval rules

    Added a new optional response field member_role_id (integer, int64 format) to six project approval rule-related API endpoints. This field represents the ID of a custom member role and is purely additive — existing integrations will continue to work unaffected.

  • Additive

    Add duo_dependency_bump_breaking_changes_enabled parameter

    A new optional boolean parameter override_params[duo_dependency_bump_breaking_changes_enabled] has been added to multiple GitLab project APIs, along with a corresponding response field. This enables GitLab Duo AI-powered resolution of breaking changes from dependency bumps and does not affect existing integrations since it is purely optional.

  • Informational

    Clarify organization parameter accepts paths in API docs

    The organization parameter documentation was updated to clarify that it accepts both organization IDs and paths (e.g., 1 or default), matching the actual API behavior. This is a documentation clarification only with no change to the API's actual functionality or behavior.

  • Additive

    New Jira Forge integration endpoints

    GitLab API adds four new endpoints for Jira Forge integration under two new tag groups (jira_forge_installation and jira_forge_subscriptions). The changes include PUT and POST operations for installation configuration, namespace subscriptions, and system token registration, along with supporting request/response models. This is purely additive and does not affect existing integrations.

  • Informational

    OpenAPI documentation improvements for group and package endpoints

    GitLab's OpenAPI specification adds summary fields and clarifies descriptions across multiple group management endpoints and package registry endpoints. The changes improve documentation clarity and endpoint discoverability without altering request/response behavior, request parameters, or response schemas.

  • Additive

    Add optional organization parameter to GitLab API filter

    A new optional organization parameter has been added to allow filtering by organization ID or comma-separated list of organization IDs. This is a purely additive change that does not affect existing integrations.

  • Additive

    Add endpoint to remove shared projects from groups

    A new DELETE endpoint DELETE /api/v4/groups/{id}/shared_projects/{project_id} has been added to allow group owners to remove shared projects. This is a purely additive change that enables new functionality without affecting existing integrations.

  • Breaking

    MR/group access/merge request review fields: int32→int64 and type changes

    Multiple response fields have been updated across merge request, group access, and merge request review entities:

    • source_project_id and target_project_id on merge request entities changed from int32 to int64 format.
    • id, user_id, group_id on group access entities changed from int32 to int64.
    • Several fields on the merge request review entity (id, author_id, merge_request_id) changed from int32 to int64.
    • discussion_id changed from type: integer, format: int32 to type: string (e.g. a SHA-like hex string).
    • commit_id changed from type: integer, format: int32 to type: string (e.g. a full commit SHA).

    The int32→int64 changes may break strongly-typed clients that allocated only 32-bit integers. The discussion_id and commit_id type changes from integer to string are breaking for any client that treats these as numeric values.

  • Informational

    GitLab API docs clarified for placeholder reassignments and events endpoints

    Documentation updates to multiple endpoints to clarify their behavior: Placeholder reassignments endpoint summary/description reworded from "pending placeholder assignments" to "pending reassignments"; POST issue links endpoint fixed grammar ("relation" → "relationship"); Events endpoints (GET /api/v4/events and GET /api/v4/users/{id}/events) updated with more detailed descriptions noting they exclude epics/merge requests and return bulk push events with limited details. No API behavior changes or breaking modifications.

  • Additive

    Add new /trigger_jobs endpoint; deprecate /bridges

    A new endpoint GET /api/v4/projects/{id}/pipelines/{pipeline_id}/trigger_jobs is added to replace the deprecated GET /api/v4/projects/{id}/pipelines/{pipeline_id}/bridges endpoint. The bridges endpoint is now marked deprecated (still functional) with a note to use trigger_jobs instead. Clients have a migration path and both endpoints work concurrently.

  • Additive

    Add member_role_id and member_role_name to group member response

    Two new optional response fields member_role_id (integer) and member_role_name (string) have been added to the group member API response. This is a purely additive change that provides additional member role metadata without affecting existing integrations.

  • Additive

    Add last_used_ips field to personal access token responses

    The last_used_ips field is now defined with explicit items: {type: string} schema and a description in the OpenAPI spec for personal access token responses. One occurrence made last_used_ips optional (removed from required list), while another added the schema definition. This enhances documentation and API clarity without breaking existing clients—the field was already returned but is now properly specified.

  • Additive

    Add uuid field to organization response

    A new required uuid field has been added to the organization response schema. This is an additive change that adds a new required response field to organization endpoints, which will not break existing clients that ignore unknown response properties.

  • Additive

    Expand integer fields from int32 to int64 format

    Multiple response fields across various GitLab API entities have had their OpenAPI type format changed from int32 to int64. This change increases the range of values these fields can represent without breaking existing clients, as int64 is a superset of int32. All affected fields are in response objects and maintain backward compatibility.

  • Informational

    Update integer format specs in API schema

    Three integer fields in the GitLab API schema have had their format specification changed from int32 to int64: id, project_id, and build_id. This reflects the actual data types returned by the API and does not change runtime behavior for clients already handling 64-bit integers correctly.

  • Informational

    Update integer format from int32 to int64 in bulk import schemas

    Several ID fields in bulk import–related response schemas changed their OpenAPI format annotation from int32 to int64. This clarifies the actual data type and does not affect runtime behavior or client integration — the underlying integers remain unchanged and compatible with existing code.

  • Additive

    Add vulnerability remediation upload metrics to usage API

    The GitLab API now includes new fields for vulnerability remediation upload metrics in the usage statistics response. These 16 new optional fields track counts, checksums, syncing, and verification status for vulnerability remediation uploads, mirroring the existing vulnerability export upload metrics structure. This is a purely additive change that does not affect existing integrations.

  • Informational

    Reorganize package-type API tags in OpenAPI spec

    The OpenAPI specification has reorganized the packages tag into multiple package-type-specific tags: packages_debian, packages_npm, packages_conan, packages_cargo, packages_composer, packages_nuget, packages_pypi, packages_helm, packages_rpm, and packages_rubygem. All endpoints remain functional and unchanged; this restructuring only affects API documentation organization and tooling that processes tags.

  • Additive

    Add read_agent_artifacts OAuth scope

    A new OAuth scope read_agent_artifacts has been added to the GitLab API specification. This is a new optional capability that applications can request; existing integrations are unaffected.

  • Breaking

    Multiple response fields widened from int32 to int64; Agent/Cluster field types corrected

    Several categories of changes are present in this diff:

    • int32 → int64 on id, project_id, and pipeline_id fields across many CI/CD, pipeline, environment, runner, and deployment response schemas. Strictly speaking this is a widening (larger value range), but strongly-typed clients that generated code from int32 may overflow or need recompilation.
    • type: string → type: integer (int64) for id, agent_id, and created_by_user_id in API_Entities_Clusters_AgentTokenBasic, API_Entities_Clusters_AgentToken, API_Entities_Clusters_AgentTokenWithToken, and API_Entities_Clusters_Agent. Any client that parsed these fields as strings will break.
    • is_receptive in API_Entities_Clusters_Agent changed from type: string to type: boolean — string-parsing clients will break.
    • created_at / last_used_at in Agent/Token schemas gained format: date-time (additive but narrows expected format).
    • API_Entities_DiscoveredClusters fields groups and projects changed from type: string to type: object — clients treating these as strings will break.
  • Informational

    Update integer format from int32 to int64 in API specs

    The OpenAPI specification was updated to correctly describe integer fields as int64 format instead of int32 in two objects. This is a documentation correction that clarifies the actual data type constraints without changing the runtime API behavior — clients are already receiving and should handle full 64-bit integers.

  • Informational

    Integer fields changed from int32 to int64 format

    Multiple integer fields across GitLab API responses have been updated from int32 to int64 format specification. This change clarifies the actual range of acceptable values for ID and numeric fields and does not affect runtime behavior or existing integrations, as the fields themselves remain integers and JSON does not distinguish between int32 and int64 at the protocol level.

  • Additive

    Add AI settings schema and widen integer field formats

    The GitLab OpenAPI spec adds a new ai_settings field to the application settings response (referencing a new API_Entities_AiSettings schema) and widens the numeric format of several integer fields from int32 to int64. The new AI_Entities_AiSettings schema includes 14 new boolean/integer fields for AI feature configuration. The int32→int64 changes are backward-compatible widening of the numeric range.

  • Additive

    Expand audit event endpoint access to Developer role

    The GET /api/v4/projects/{id}/audit_events/{audit_event_id} endpoint now allows access for users with the Developer role (or higher), previously restricted to Maintainer or Owner only. This broadens access to the endpoint, enabling more team members to retrieve project audit events without breaking existing integrations.

  • Informational

    Change integer ID format from int32 to int64 in API schema

    The OpenAPI specification was updated to change the format property of integer id fields from int32 to int64 across multiple schema objects. This reflects the actual data type representation but does not alter the API behavior or response structure; existing integrations will continue to work unchanged.

  • Breaking

    project_id format changed from int32 to int64 in storage response

    The project_id field's format was updated from int32 to int64 in a response schema. Clients that deserialize this field into a 32-bit integer type will silently overflow or error for project IDs exceeding 2,147,483,647, which is a real concern for large GitLab instances. Any generated SDK code or typed client that mapped int32 will need to be updated.

  • Informational

    Widen integer fields from int32 to int64 in package/release schemas

    Multiple id and project_id fields across package registry, release, and cleanup policy schemas have had their OpenAPI format widened from int32 to int64. This is a spec correction to accurately reflect that GitLab IDs can exceed the 32-bit integer range. Most API clients do not enforce the format hint at runtime, so this is unlikely to break existing integrations — but generated client code (e.g. from OpenAPI codegen) may produce different types (int vs long/int64) after regeneration.

  • Informational

    Update integer format from int32 to int64 in OpenAPI schema

    Multiple integer fields in the OpenAPI specification have been changed from int32 format to int64 format. This is a documentation/schema update that clarifies the actual range of values these fields support; it does not break existing integrations since clients already handle these values correctly.

  • Additive

    Add merge_train_enforcement field to project settings

    A new optional response field merge_train_enforcement has been added to the project settings schema. This field is a string enum that can be one of allow_bypass, enforce_for_all_users, or enforce_with_owner_override, allowing GitLab to communicate merge train enforcement policies in API responses.

  • Additive

    Add destroy_package capability to user permissions

    Added a new optional destroy_package boolean field to the user capabilities response schema. This is a new capability that can be returned in API responses to indicate whether a user has permission to destroy packages, and does not affect existing clients.

  • Additive

    Add severity field to issue responses

    The GitLab API now includes a new optional severity field in issue response objects. This field applies only to incidents and accepts values: unknown, low, medium, high, or critical. Existing integrations are unaffected as this is a purely additive change to the response schema.

  • Additive

    Add dependency list export part uploads metrics to Geo API

    GitLab's Geo API now includes 15 new optional response fields for dependency list export part uploads metrics, including count, checksum, sync, and verification statistics. These additions enable monitoring and tracking of dependency list export replication in Geo deployments without breaking existing integrations.