GitLab is not a source-control company that grew an API. It is a DevOps platform whose API is the platform. The provider profile on APIs.io indexes 41 APIs, and reading them in one place makes the design philosophy obvious: everything from a commit to a compliance scan is a resource you can drive programmatically.
GitLab describes itself as an open-core company building software for building, securing, and managing applications, with roughly 30 million registered users and 1 million active licensed users. The API surface is the machine-readable version of that mission statement.
What’s in the surface
The catalog carries machine-readable OpenAPI for each seam of the platform. Sampling the specs:
- Groups API and Projects API — create, read, update, and delete the containers that organize access and work.
- Admin API and Application Settings API — instance-level administration, runners, and CI/CD variables.
- Pipelines, Jobs, and Runners APIs — the CI/CD core: list, create, retry, and cancel builds.
- Merge Requests, Issues, Commits, Branches, and Protected Branches — the code-review and change-control loop.
- Vulnerabilities API and Container Registry API — the security and supply-chain seam.
Alongside the REST specs sit a GitLab GraphQL API, a GitLab OAuth 2.0 API, and GitLab Webhooks — described both as an OpenAPI contract and as an event-driven AsyncAPI specification.
What’s interesting
Two things stand out.
First, the breadth is genuinely DevSecOps, not just DevOps. The Vulnerabilities API lets you retrieve, confirm, resolve, and dismiss security findings. Protected Branches and Deploy Keys govern who can push and merge. This is governance-as-API, not a bolt-on.
Second, GitLab is built for agents to act, not just read. The provider carries an agentic-access contract covering 167 operations, of which 92 are classified as acting and just 1 is flagged human-in-the-loop. That is a deliberate posture: most of the platform is safe to automate, with a thin layer held back for human judgment.
The reinforcing signals are all present — an authentication contract with three schemes, published rate limits, a trust center listing SOC 2 and ISO 27001, and Spectral governance rulesets checking the specs themselves. GitLab scores a composite 64.6 (strong band) and an agent-readiness score of 48.1 (agent-ready), the latter carried by spec presence, agentic access, auth clarity, and rate-limit signaling.
Takeaway
GitLab is what a one-platform API strategy looks like when it is finished. Instead of scattering source control, CI/CD, registries, and security across separate products with separate integration stories, GitLab exposes them as one coherent, contract-first surface. If you are building tooling, bots, or agents against the software-delivery lifecycle, this is a reference implementation worth studying. Start at the GitLab profile on APIs.io and walk the 41 specs.