---
title: "Supported openEO versions"
method: GET
path: "/.well-known/openeo"
tags: ["Capabilities"]
---

# Supported openEO versions

`GET /.well-known/openeo`

Lists all implemented openEO versions supported by the
service provider. This endpoint is the Well-Known URI
(see [RFC 5785](https://www.rfc-editor.org/rfc/rfc5785.html)) for openEO.

This allows a client to easily identify the most recent openEO
implementation it supports. By default, a client SHOULD connect to the
most recent production-ready version it supports. If not available, the
most recent supported version of *all* versions SHOULD be connected to.
Clients MAY let users choose to connect to versions that are not
production-ready or outdated.
The most recent version is determined by comparing the version numbers
according to rules from [Semantic Versioning](https://semver.org/),
especially [§11](https://semver.org/#spec-item-11). Any pair of API
versions in this list MUST NOT be equal according to Semantic Versioning.

The Well-Known URI is the entry point for clients and users, so make
sure it is permanent and easy to use and remember. Clients MUST NOT
require the well-known path (`/.well-known/openeo`) in the URL that is
specified by a user to connect to the back-end.

For clients, the usual behavior SHOULD follow these steps:
1. The user provides a URI, which may consist of a scheme (protocol), 
   an authority (host, port) and a path.
2. The client parses the URI and appends `/.well-knwon/openeo` to the
   path. Make sure to correctly handle leading/trailing slashes.
3. Send a request to the new URI.
   A. On success: Detect the most suitable API instance/version (see above)
      and read the [capabilities](#tag/Capabilities/operation/capabilities)
      from there.
   B. On failure: Directly try to read the capabilities from the original URI
      given by the user.

**This URI MUST NOT be versioned as the other endpoints.**
If your API is available at `https://openeo.example/api/v1`, and
you instruct your API users to use `https://openeo.example` as connection URI, 
the Well-Known URI SHOULD be located at `https://openeo.example/.well-known/openeo`.
The Well-Known URI is usually directly located at the top-level, but it is not a
requirement. For example, `https://openeo.example/eo/.well-known/openeo` is also allowed.

Clients MAY get additional information (e.g. title or description) about
a back-end from the most recent version that has the `production` flag
set to `true`.

## Response `200`

List of all available API instances, each with URL and the implemented openEO API version.

- object
  - `versions` object[], required
    - `url` string, uri, required — *Absolute* URLs to the service.
    - `production` boolean — Specifies whether the implementation is ready to be used in production use (`true`) or not (`false`). Clients SHOULD only connect to non-production implementations if the user explicitly confirmed to use a non-production implementation. This flag is part of `GET /.well-known/openeo` and `GET /`. It MUST be used consistently in both endpoints.
    - `api_version` string, required — Version number of the openEO specification this back-end implements.

## Other responses

- `4XX` — The request can not be fulfilled due to an error on client-side, i.e. the request is invalid. The client SHOULD NOT repeat the request without modifications. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). This request usually does not respond with HTTP status codes 401 and 403 due to missing authorization. HTTP status code 404 SHOULD be used if the value of a path parameter is invalid. See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json)
- `5XX` — The request can not be fulfilled due to an error at the back-end. The error is never the client’s fault and therefore it is reasonable for the client to retry the exact same request that triggered this response. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json)

---

[API](https://skmtc.net/open-eo/apis/openeo-api.md) · [All operations](https://skmtc.net/open-eo/apis/openeo-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/open-eo/openeo-api/versions/0c5e31955a19/schema)