openapi: 3.1.2 info: description: "You're looking at the current **stable** documentation of the OpenProject APIv3. If you're interested in the current\ndevelopment version, please go to [github.com/opf](https://github.com/opf/openproject/tree/dev/docs/api/apiv3).\n\n## Introduction\n\nThe documentation for the APIv3 is written according to the [OpenAPI 3.1 Specification](https://swagger.io/specification/).\nYou can either view the static version of this documentation on the [website](https://www.openproject.org/docs/api/introduction/)\nor the interactive version, rendered with [OpenAPI Explorer](https://github.com/Rhosys/openapi-explorer/blob/main/README.md),\nin your OpenProject installation under `/api/docs`.\nIn the latter you can try out the various API endpoints directly interacting with our OpenProject data.\nMoreover you can access the specification source itself under `/api/v3/spec.json` and `/api/v3/spec.yml`\n(e.g. [here](https://community.openproject.org/api/v3/spec.yml)).\n\nThe APIv3 is a hypermedia REST API, a shorthand for \"Hypermedia As The Engine Of Application State\" (HATEOAS).\nThis means that each endpoint of this API will have links to other resources or actions defined in the resulting body.\n\nThese related resources and actions for any given resource will be context sensitive. For example, only actions that the\nauthenticated user can take are being rendered. This can be used to dynamically identify actions that the user might take for any\ngiven response.\n\nAs an example, if you fetch a work package through the [Work Package endpoint](https://www.openproject.org/docs/api/endpoints/work-packages/), the `update` link will only\nbe present when the user you authenticated has been granted a permission to update the work package in the assigned project.\n\n## HAL+JSON\n\nHAL is a simple format that gives a consistent and easy way to hyperlink between resources in your API.\nRead more in the following specification: [https://tools.ietf.org/html/draft-kelly-json-hal-08](https://tools.ietf.org/html/draft-kelly-json-hal-08)\n\n**OpenProject API implementation of HAL+JSON format** enriches JSON and introduces a few meta properties:\n\n- `_type` - specifies the type of the resource (e.g.: WorkPackage, Project)\n- `_links` - contains all related resource and action links available for the resource\n- `_embedded` - contains all embedded objects\n\nHAL does not guarantee that embedded resources are embedded in their full representation, they might as well be\npartially represented (e.g. some properties can be left out).\nHowever in this API you have the guarantee that whenever a resource is **embedded**, it is embedded in its **full representation**.\n\n## API response structure\n\nAll API responses contain a single HAL+JSON object, even collections of objects are technically represented by\na single HAL+JSON object that itself contains its members. More details on collections can be found\nin the [Collections Section](https://www.openproject.org/docs/api/collections/).\n\n## Authentication\n\nThe API supports the following authentication schemes:\n\n* Session-based authentication\n* API tokens\n * passed as Bearer token\n * passed via Basic auth\n* OAuth 2.0\n * using built-in authorization server\n * using an external authorization server (RFC 9068)\n\nDepending on the settings of the OpenProject instance many resources can be accessed without being authenticated.\nIn case the instance requires authentication on all requests the client will receive an **HTTP 401** status code\nin response to any request.\n\nOtherwise unauthenticated clients have all the permissions of the anonymous user.\n\n### Session-based authentication\n\nThis means you have to login to OpenProject via the Web-Interface to be authenticated in the API.\nThis method is well-suited for clients acting within the browser, like the Angular-Client built into OpenProject.\n\nIn this case, you always need to pass the HTTP header `X-Requested-With \"XMLHttpRequest\"` for authentication.\n\n### API token as bearer token\n\nUsers can authenticate towards the API v3 using an API token as a bearer token.\n\nFor example:\n\n```shell\nAPI_KEY=opapi-2519132cdf62dcf5a66fd96394672079f9e9cad1\ncurl -H \"Authorization: Bearer $API_KEY\" https://community.openproject.org/api/v3/users/42\n```\n\nUsers can generate API tokens on their account page.\n\n### API token through Basic Auth\n\nAPI tokens can also be used with basic auth, using the user name `apikey` (NOT your login) and the API token as the password.\n\nFor example:\n\n```shell\nAPI_KEY=opapi-2519132cdf62dcf5a66fd96394672079f9e9cad1\ncurl -u apikey:$API_KEY https://community.openproject.org/api/v3/users/42\n```\n\n### OAuth 2.0 authentication\n\nOpenProject allows authentication and authorization with OAuth2 with *Authorization code flow*, as well as *Client credentials* operation modes.\n\nTo get started, you first need to register an application in the OpenProject OAuth administration section of your installation.\nThis will save an entry for your application with a client unique identifier (`client_id`) and an accompanying secret key (`client_secret`).\n\nYou can then use one the following guides to perform the supported OAuth 2.0 flows:\n\n- [Authorization code flow](https://oauth.net/2/grant-types/authorization-code)\n\n- [Authorization code flow with PKCE](https://doorkeeper.gitbook.io/guides/ruby-on-rails/pkce-flow), recommended for clients unable to keep the client_secret confidential\n\n- [Client credentials](https://oauth.net/2/grant-types/client-credentials/) - Requires an application to be bound to an impersonating user for non-public access\n\n### OAuth 2.0 using an external authorization server\n\nThere is a possibility to use JSON Web Tokens (JWT) generated by an OIDC provider configured in OpenProject as a bearer token to do authenticated requests against the API.\nThe following requirements must be met:\n\n- OIDC provider must be configured in OpenProject with **jwks_uri**\n- JWT must be signed using RSA algorithm\n- JWT **iss** claim must be equal to OIDC provider **issuer**\n- JWT **aud** claim must contain the OpenProject **client ID** used at the OIDC provider\n- JWT **scope** claim must include a valid scope to access the desired API (e.g. `api_v3` for APIv3)\n- JWT must be actual (neither expired or too early to be used)\n- JWT must be passed in Authorization header like: `Authorization: Bearer {jwt}`\n- User from **sub** claim must be linked to OpenProject before (e.g. by logging in), otherwise it will be not authenticated\n\nIn more general terms, OpenProject should be compliant to [RFC 9068](https://www.rfc-editor.org/rfc/rfc9068) when validating access tokens.\n\n### Why not username and password?\n\nThe simplest way to do basic auth would be to use a user's username and password naturally.\nHowever, OpenProject already has supported API keys in the past for the API v2, though not through basic auth.\n\nUsing **username and password** directly would have some advantages:\n\n* It is intuitive for the user who then just has to provide those just as they would when logging into OpenProject.\n\n* No extra logic for token management necessary.\n\nOn the other hand using **API keys** has some advantages too, which is why we went for that:\n\n* If compromised while saved on an insecure client the user only has to regenerate the API key instead of changing their password, too.\n\n* They are naturally long and random which makes them invulnerable to dictionary attacks and harder to crack in general.\n\nMost importantly users may not actually have a password to begin with. Specifically when they have registered\nthrough an OpenID Connect provider.\n\n## Cross-Origin Resource Sharing (CORS)\n\nBy default, the OpenProject API is _not_ responding with any CORS headers.\nIf you want to allow cross-domain AJAX calls against your OpenProject instance, you need to enable CORS headers being returned.\n\nPlease see [our API settings documentation](https://www.openproject.org/docs/system-admin-guide/api-and-webhooks/) on\nhow to selectively enable CORS.\n\n## Allowed HTTP methods\n\n- `GET` - Get a single resource or collection of resources\n\n- `POST` - Create a new resource or perform\n\n- `PATCH` - Update a resource\n\n- `DELETE` - Delete a resource\n\n## Compression\n\nResponses are compressed if requested by the client. Currently [gzip](https://www.gzip.org/) and [deflate](https://tools.ietf.org/html/rfc1951)\nare supported. The client signals the desired compression by setting the [`Accept-Encoding` header](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3).\nIf no `Accept-Encoding` header is send, `Accept-Encoding: identity` is assumed which will result in the API responding uncompressed." title: OpenProject API V3 (Stable) Actions & Capabilities Views API version: '3' servers: - url: https://qa.openproject-edge.com description: Edge QA instance - url: https://qa.openproject-stage.com description: Staging instance - url: https://community.openproject.org description: Community instance security: - BasicAuth: [] tags: - description: "A View is a representation of some information. That information might be a query (currently it always is).\nThe view will store the configuration on how to display the information but not the information itself.\n\nA View might then be a graph, a table, a gantt chart or something completely different.\nThe client will have to choose how to represenent in the view. \n\nA View instance will always be of a subtype of `Views`, e.g. `Views::WorkPackageslist`. The properties between each `Views` type might differ a lot.\n\n**The View is a new concept so it is prone to change.**\n\nCurrently a lot of restrictions still apply:\n * There will always be a query associated to the view when in the complete concept, this limitation should not be necessary.\n * A query can only have one view associated.\n * There is neither an update nor a delete endpoint and the schema and form endpoints are also missing. \n To delete a view, simply delete the query.\n * Most of the properties are deduced from the associated query and can thus only be updated via updating the query.\n * The properties are not different between `Views` subtypes.\n\n## Linked Properties\n\n| Link | Description | Type | Constraints | Supported operations |\n| :-------------------: | ---------------------------------------- | ------------- | -------- | -------------------- |\n| self | This view | View (a subtype of it) | not null | READ |\n| query | This query from which to fetch the data | Query | not null | READ/WRITE |\n| project | This project the view is defined in (deduces from the query). If no project is specified, the View is considered global. | Project | Deduced from the query | READ |\n\n## Local Properties\n\n| Property | Description | Type | Constraints | Supported operations|\n| :--------------: | ------------------------------------------------------| ----------- | ------------------------------------ | --------------------|\n| _type | The subtype chosen | String | | READ |\n| id | View id | Integer | x > 0 | READ |\n| name | View name | String | Deduced from the query | READ |\n| public | Can users besides the owner see the view? | Boolean | Deduced from the query | READ |\n| starred | Should the view be highlighted to the user? | Boolean | Deduced from the query | READ |\n| createdAt | Time of creation | DateTime | not null | READ |\n| updatedAt | Time of the most recent change to the view | DateTime | not null | READ |" name: Views paths: /api/v3/views: get: parameters: - description: 'JSON specifying filter conditions. Currently supported filters are: + project: filters views by the project their associated query is assigned to. If the project filter is passed with the `!*` (not any) operator, global views are returned. + id: filters views based on their id + type: filters views based on their type' example: '[{ "project_id": { "operator": "!*", "values": null }" }]' in: query name: filters required: false schema: type: string responses: '200': content: application/hal+json: examples: Queries: $ref: '#/components/examples/Views' description: OK headers: {} tags: - Views description: Returns a collection of Views. The collection can be filtered via query parameters similar to how work packages are filtered. operationId: List_views summary: List views /api/v3/views/{id}: get: parameters: - description: View id example: 42 in: path name: id required: true schema: type: integer responses: '200': content: application/hal+json: examples: ViewWorkPackagesTable: $ref: '#/components/examples/ViewWorkPackagesTable' ViewTeamPlanner: $ref: '#/components/examples/ViewTeamPlanner' description: Returns the result of a single view, dependent of the view type. '400': $ref: '#/components/responses/InvalidRequestBody' '403': content: application/hal+json: schema: $ref: '#/components/schemas/ErrorResponse' examples: response: value: _type: Error errorIdentifier: urn:openproject-org:api:v3:errors:MissingPermission message: You are not authorized to access this resource. description: 'Returned if the client does not have sufficient permissions. **Required permission:** The required permission depends on the type of the view.' headers: {} '404': content: application/hal+json: schema: $ref: '#/components/schemas/ErrorResponse' examples: response: value: _type: Error errorIdentifier: urn:openproject-org:api:v3:errors:NotFound message: The requested resource could not be found. description: 'Returned if the resource can not be found. *Note: A client without sufficient permissions shall not be able to test for the existence of a view. That''s why a 404 is returned here, even if a 403 might be more appropriate.*' headers: {} tags: - Views description: '' operationId: View_view summary: View view post: parameters: - description: The view identifier name: id in: path required: true example: 1 schema: type: string requestBody: content: application/json: examples: Views::WorkPackagesTable: value: _links: query: href: /api/v3/queries/5 Views::TeamPlanner: value: _links: query: href: /api/v3/queries/5 schema: type: object properties: _links: type: object properties: query: type: object properties: href: type: string format: uri responses: '201': content: application/hal+json: schema: type: object examples: Views::WorkPackagesTable: $ref: '#/components/examples/ViewWorkPackagesTable' Views::TeamPlanner: $ref: '#/components/examples/ViewTeamPlanner' description: Created headers: {} '400': $ref: '#/components/responses/InvalidRequestBody' '406': $ref: '#/components/responses/MissingContentType' '415': $ref: '#/components/responses/UnsupportedMediaType' '422': content: application/hal+json: schema: $ref: '#/components/schemas/ErrorResponse' examples: response: value: _embedded: details: attribute: query _type: Error errorIdentifier: urn:openproject-org:api:v3:errors:PropertyConstraintViolation message: Query does not exist. description: "Returned if:\n\n* the client tries to modify a read-only property (`PropertyIsReadOnly`)\n\n* a constraint for a property was violated (`PropertyConstraintViolation`)\n\n* the client provides a link to an invalid resource (`ResourceTypeMismatch`),\n e.g. a query not found" headers: {} tags: - Views description: "When calling this endpoint the client provides a single object, containing at least the properties and links that are required, in the body.\nThe required fields of a View can be found in its schema, which is embedded in the respective form.\nNote that it is only allowed to provide properties or links supporting the write operation.\n\nThere are different subtypes of `Views` (e.g. `Views::WorkPackagesTable`) with each having its own\nendpoint for creating that subtype e.g.\n\n* `/api/v3/views/work_packages_table` for `Views::WorkPackagesTable`\n* `/api/v3/views/team_planner` for `Views::TeamPlanner`\n* `/api/v3/views/work_packages_calendar` for `Views::WorkPackagesCalendar`\n\n**Not yet implemented** To get the list of available subtypes and by that the endpoints for creating a subtype, use the\n```\n /api/v3/views/schemas\n```\nendpoint." operationId: Create_views summary: Create view components: examples: ViewTeamPlanner: value: _type: Views::TeamPlanner name: Product team id: 9 _links: self: href: /api/v3/views/9 query: href: /api/v3/queries/18 title: Product team project: href: /api/v3/project/89 title: The project ViewWorkPackagesTable: value: _type: Views::WorkPackagesTable name: Current work packages id: 9 _links: self: href: /api/v3/views/9 query: href: /api/v3/queries/18 title: Current work packages project: href: /api/v3/project/89 title: The project Views: value: _links: self: href: /api/v3/views changeSize: href: /api/v3/views?pageSize={size} templated: true jumpTo: href: /api/v3/views?offset={offset} templated: true total: 1 count: 1 _type: Collection _embedded: elements: - _type: Views::WorkPackagesTable name: Current work packages timelineVisible: true id: 9 _links: self: href: /api/v3/views/9 query: href: /api/v3/queries/18 title: A query columns: - href: /api/v3/users/id title: ID - href: /api/v3/users/subject title: Subject - href: /api/v3/users/type title: Type - href: /api/v3/users/status title: Status - href: /api/v3/users/priority title: Priority - href: /api/v3/users/assignee title: Assignee - href: /api/v3/users/updated_at title: Updated on project: href: /api/v3/project/89 title: The project schemas: ErrorResponse: type: object required: - _type - errorIdentifier - message properties: _embedded: type: object properties: details: type: object properties: attribute: type: string example: project _type: type: string enum: - Error errorIdentifier: type: string example: urn:openproject-org:api:v3:errors:PropertyConstraintViolation message: type: string example: Project can't be blank. responses: MissingContentType: description: Occurs when the client did not send a Content-Type header content: text/plain: schema: type: string example: Missing content-type header InvalidRequestBody: description: Occurs when the client did not send a valid JSON object in the request body. content: application/hal+json: schema: $ref: '#/components/schemas/ErrorResponse' example: _type: Error errorIdentifier: urn:openproject-org:api:v3:errors:InvalidRequestBody message: The request body was not a single JSON object. UnsupportedMediaType: description: Occurs when the client sends an unsupported Content-Type header. content: application/hal+json: schema: $ref: '#/components/schemas/ErrorResponse' example: _type: Error errorIdentifier: urn:openproject-org:api:v3:errors:TypeNotSupported message: Expected CONTENT-TYPE to be (expected value) but got (actual value). securitySchemes: BasicAuth: type: http scheme: basic