README.md 12.0 KB
Newer Older
1
# GitLab API
N
Nihad Abbasov 已提交
2

3
Automate GitLab via a simple and powerful API. All definitions can be found
4
under [`/lib/api`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/api).
5

6
## Resources
7

8 9 10
Documentation for various API resources can be found separately in the
following locations:

11
- [Award Emoji](award_emoji.md)
12
- [Branches](branches.md)
13
- [Broadcast Messages](broadcast_messages.md)
A
Achilleas Pipinellis 已提交
14
- [Builds](builds.md)
15
- [Build Triggers](build_triggers.md)
A
Achilleas Pipinellis 已提交
16 17
- [Build Variables](build_variables.md)
- [Commits](commits.md)
18
- [Deployments](deployments.md)
A
Achilleas Pipinellis 已提交
19 20
- [Deploy Keys](deploy_keys.md)
- [Groups](groups.md)
21 22
- [Group Access Requests](access_requests.md)
- [Group Members](members.md)
23
- [Issues](issues.md)
A
Achilleas Pipinellis 已提交
24
- [Keys](keys.md)
R
Robert Schilling 已提交
25
- [Labels](labels.md)
A
Achilleas Pipinellis 已提交
26
- [Merge Requests](merge_requests.md)
27
- [Milestones](milestones.md)
A
Achilleas Pipinellis 已提交
28
- [Open source license templates](licenses.md)
29
- [Namespaces](namespaces.md)
A
Achilleas Pipinellis 已提交
30
- [Notes](notes.md) (comments)
31
- [Notification settings](notification_settings.md)
32
- [Pipelines](pipelines.md)
A
Achilleas Pipinellis 已提交
33
- [Projects](projects.md) including setting Webhooks
34 35
- [Project Access Requests](access_requests.md)
- [Project Members](members.md)
A
Achilleas Pipinellis 已提交
36 37 38
- [Project Snippets](project_snippets.md)
- [Repositories](repositories.md)
- [Repository Files](repository_files.md)
39
- [Runners](runners.md)
A
Achilleas Pipinellis 已提交
40 41 42
- [Services](services.md)
- [Session](session.md)
- [Settings](settings.md)
43
- [Sidekiq metrics](sidekiq_metrics.md)
A
Achilleas Pipinellis 已提交
44 45
- [System Hooks](system_hooks.md)
- [Tags](tags.md)
46
- [Todos](todos.md)
47
- [Users](users.md)
48
- [Validate CI configuration](ci/lint.md)
A
Achilleas Pipinellis 已提交
49 50 51 52 53 54 55

### Internal CI API

The following documentation is for the [internal CI API](ci/README.md):

- [Builds](ci/builds.md)
- [Runners](ci/runners.md)
56

57
## Authentication
58

59 60 61
All API requests require authentication via a session cookie or token. There are
three types of tokens available: private tokens, OAuth 2 tokens, and personal
access tokens.
N
Nihad Abbasov 已提交
62

63 64
If authentication information is invalid or omitted, an error message will be
returned with status code `401`:
N
Nihad Abbasov 已提交
65 66 67 68 69 70 71

```json
{
  "message": "401 Unauthorized"
}
```

72
### Private Tokens
N
Nihad Abbasov 已提交
73

74 75
You need to pass a `private_token` parameter via query string or header. If passed as a
header, the header name must be `PRIVATE-TOKEN` (uppercase and with a dash instead of
76 77
an underscore). You can find or reset your private token in your account page
(`/profile/account`).
N
Nihad Abbasov 已提交
78

79
### OAuth 2 Tokens
N
Nihad Abbasov 已提交
80

81 82 83 84
You can use an OAuth 2 token to authenticate with the API by passing it either in the
`access_token` parameter or in the `Authorization` header.

Example of using the OAuth2 token in the header:
85

86
```shell
87
curl --header "Authorization: Bearer OAUTH-TOKEN" https://gitlab.example.com/api/v3/projects
88 89
```

90 91 92
Read more about [GitLab as an OAuth2 client](oauth2.md).

### Personal Access Tokens
N
Nihad Abbasov 已提交
93

94
> [Introduced][ce-3749] in GitLab 8.8.
V
Valery Sizov 已提交
95

96
You can create as many personal access tokens as you like from your GitLab
97 98
profile (`/profile/personal_access_tokens`); perhaps one for each application
that needs access to the GitLab API.
V
Valery Sizov 已提交
99

100 101
Once you have your token, pass it to the API using either the `private_token`
parameter or the `PRIVATE-TOKEN` header.
102

103

A
Alan Moore 已提交
104
### Session Cookie
105 106 107 108 109

When signing in to GitLab as an ordinary user, a `_gitlab_session` cookie is
set. The API will use this cookie for authentication if it is present, but using
the API to generate a new session cookie is currently not supported.

110 111 112 113 114 115
## Basic Usage

API requests should be prefixed with `api` and the API version. The API version
is defined in [`lib/api.rb`][lib-api-url].

Example of a valid API request:
V
Valery Sizov 已提交
116

117
```shell
118
GET https://gitlab.example.com/api/v3/projects?private_token=9koXpg98eAheJpvBs5tK
V
Valery Sizov 已提交
119 120
```

121
Example of a valid API request using cURL and authentication via header:
V
Valery Sizov 已提交
122

123
```shell
124
curl --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/projects"
V
Valery Sizov 已提交
125 126
```

127 128
The API uses JSON to serialize data. You don't need to specify `.json` at the
end of an API URL.
V
Valery Sizov 已提交
129

130 131
## Status codes

132
The API is designed to return different status codes according to context and
133
action. This way, if a request results in an error, the caller is able to get
134 135 136 137
insight into what went wrong.

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

138
| Request type | Description |
139 140 141 142
| ------------ | ----------- |
| `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` / `DELETE` | Return `200 OK` if the resource is accessed, modified or deleted successfully. The (modified) result is returned as JSON. |
143
| `DELETE` | Designed to be idempotent, meaning a request to a resource still returns `200 OK` even it was deleted before or is not available. The reasoning behind this, is that the user is not really interested if the resource existed before or not. |
144 145 146

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

147
| Return values | Description |
148 149 150
| ------------- | ----------- |
| `200 OK` | The `GET`, `PUT` or `DELETE` request was successful, the resource(s) itself is returned as JSON. |
| `201 Created` | The `POST` request was successful and the resource is returned as JSON. |
151
| `304 Not Modified` | Indicates that the resource has not been modified since the last request. |
152
| `400 Bad Request` | A required attribute of the API request is missing, e.g., the title of an issue is not given. |
153
| `401 Unauthorized` | The user is not authenticated, a valid [user token](#authentication) is necessary. |
154 155
| `403 Forbidden` | The request is not allowed, e.g., the user is not allowed to delete a project. |
| `404 Not Found` | A resource could not be accessed, e.g., an ID for a resource could not be found. |
156
| `405 Method Not Allowed` | The request is not supported. |
157
| `409 Conflict` | A conflicting resource already exists, e.g., creating a project with a name that already exists. |
158
| `422 Unprocessable` | The entity could not be processed. |
159
| `500 Server Error` | While handling the request something went wrong server-side. |
160

161
## Sudo
162

163
All API requests support performing an API call as if you were another user,
164
provided your private token is from an administrator account. You need to pass
165 166 167
the `sudo` parameter either via query string or a header with an ID/username of
the user you want to perform the operation as. If passed as a header, the
header name must be `SUDO` (uppercase).
168

169 170
If a non administrative `private_token` is provided, then an error message will
be returned with status code `403`:
171 172 173

```json
{
174
  "message": "403 Forbidden - Must be admin to use sudo"
175 176 177
}
```

178
If the sudo user ID or username cannot be found, an error message will be
179
returned with status code `404`:
180 181 182 183 184 185 186

```json
{
  "message": "404 Not Found: No user id or username for: <id/username>"
}
```

187 188 189 190
---

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

192 193
```shell
GET /projects?private_token=9koXpg98eAheJpvBs5tK&sudo=username
194
```
195

196
```shell
197
curl --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" --header "SUDO: username" "https://gitlab.example.com/api/v3/projects"
198 199
```

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

203
```shell
204
GET /projects?private_token=9koXpg98eAheJpvBs5tK&sudo=23
205
```
206

207 208
```shell
curl --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" --header "SUDO: 23" "https://gitlab.example.com/api/v3/projects"
209
```
210

D
Dmitriy Zaporozhets 已提交
211
## Pagination
N
Nihad Abbasov 已提交
212

213 214
Sometimes the returned result will span across many pages. When listing
resources you can pass the following parameters:
N
Nihad Abbasov 已提交
215

216 217
| Parameter | Description |
| --------- | ----------- |
218 219
| `page`    | Page number (default: `1`) |
| `per_page`| Number of items to list per page (default: `20`, max: `100`) |
N
Nihad Abbasov 已提交
220

221 222 223
In the example below, we list 50 [namespaces](namespaces.md) per page.

```bash
224
curl --request PUT --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/namespaces?per_page=50
225 226
```

227
### Pagination Link header
228

229
[Link headers](http://www.w3.org/wiki/LinkHeader) are sent back with each
230 231
response. They have `rel` set to prev/next/first/last and contain the relevant
URL. Please use these links instead of generating your own URLs.
232

233 234 235 236 237
In the cURL example below, we limit the output to 3 items per page (`per_page=3`)
and we request the second page (`page=2`) of [comments](notes.md) of the issue
with ID `8` which belongs to the project with ID `8`:

```bash
238
curl --head --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" https://gitlab.example.com/api/v3/projects/8/issues/8/notes?per_page=3&page=2
239 240
```

241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259
The response will then be:

```
HTTP/1.1 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/v3/projects/8/issues/8/notes?page=1&per_page=3>; rel="prev", <https://gitlab.example.com/api/v3/projects/8/issues/8/notes?page=3&per_page=3>; rel="next", <https://gitlab.example.com/api/v3/projects/8/issues/8/notes?page=1&per_page=3>; rel="first", <https://gitlab.example.com/api/v3/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
260 261 262 263
```

### Other pagination headers

264 265 266 267 268 269 270 271 272 273
Additional pagination headers are also sent back.

| Header | Description |
| ------ | ----------- |
| `X-Total`       | The total number of items |
| `X-Total-Pages` | The total number of pages |
| `X-Per-Page`    | The number of items per page |
| `X-Page`        | The index of the current page (starting at 1) |
| `X-Next-Page`   | The index of the next page |
| `X-Prev-Page`   | The index of the previous page |
274

275
## `id` vs `iid`
D
Dmitriy Zaporozhets 已提交
276

277 278 279 280
When you work with the API, you may notice two similar fields in API entities:
`id` and `iid`. The main difference between them is scope.

For example, an issue might have `id: 46` and `iid: 5`.
281

282 283
| Parameter | Description |
| --------- | ----------- |
284 285
| `id`  | Is unique across all issues and is used for any API call |
| `iid` | Is unique only in scope of a single project. When you browse issues or merge requests with the Web UI, you see the `iid` |
D
Dmitriy Zaporozhets 已提交
286

287
That means that if you want to get an issue via the API you should use the `id`:
288 289

```bash
290
GET /projects/42/issues/:id
291
```
D
Dmitriy Zaporozhets 已提交
292

293 294
On the other hand, if you want to create a link to a web page you should use
the `iid`:
D
Dmitriy Zaporozhets 已提交
295

296
```bash
297
GET /projects/42/issues/:iid
298
```
J
jubianchi 已提交
299 300 301

## Data validation and error reporting

302
When working with the API you may encounter validation errors, in which case
303 304
the API will answer with an HTTP `400` status.

J
jubianchi 已提交
305 306
Such errors appear in two cases:

307
- A required attribute of the API request is missing, e.g., the title of an
308
  issue is not given
309
- An attribute did not pass the validation, e.g., user bio is too long
J
jubianchi 已提交
310 311 312

When an attribute is missing, you will get something like:

313
```
314 315 316 317 318 319
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "message":"400 (Bad request) \"title\" not given"
}
```
J
jubianchi 已提交
320

321 322
When a validation error occurs, error messages will be different. They will
hold all details of validation errors:
323

324
```
325 326 327 328 329 330 331
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "message": {
        "bio": [
            "is too long (maximum is 255 characters)"
        ]
J
jubianchi 已提交
332
    }
333 334
}
```
J
jubianchi 已提交
335

336 337
This makes error messages more machine-readable. The format can be described as
follows:
J
jubianchi 已提交
338

339 340 341 342 343 344 345 346 347
```json
{
    "message": {
        "<property-name>": [
            "<error-message>",
            "<error-message>",
            ...
        ],
        "<embed-entity>": {
J
jubianchi 已提交
348 349 350 351 352 353 354
            "<property-name>": [
                "<error-message>",
                "<error-message>",
                ...
            ],
        }
    }
355 356 357
}
```

D
Dmitriy Zaporozhets 已提交
358
## Unknown route
359

D
Dmitriy Zaporozhets 已提交
360
When you try to access an API URL that does not exist you will receive 404 Not Found.
361 362

```
363
HTTP/1.1 404 Not Found
364 365
Content-Type: application/json
{
366
    "error": "404 Not Found"
367 368 369 370
}
```


371 372 373
## Clients

There are many unofficial GitLab API Clients for most of the popular
374
programming languages. Visit the [GitLab website] for a complete list.
375

376 377
[GitLab website]: https://about.gitlab.com/applications/#api-clients "Clients using the GitLab API"
[lib-api-url]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/api/api.rb
378
[ce-3749]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3749