--- title: "Information about the back-end" method: GET path: "/" tags: ["Capabilities"] --- # Information about the back-end `GET /` Lists general information about the back-end, including which version and endpoints of the openEO API are supported. May also include billing information. ## Response `200` Information about the API version and supported endpoints / features. This endpoint MUST always be available for the API to be valid. - object - `api_version` '1.3.0', required — Version number of the openEO API specification the back-end implements. - `backend_version` string, required — Version number of the back-end implementation. Every change on back-end side MUST cause a change of the version number. - `stac_version` string, required — The [version of the STAC specification](https://github.com/radiantearth/stac-spec/releases), which MAY not be equal to the [STAC API version](#tag/EO-Data-Discovery/STAC). The openEO API allows for the STAC versions 1.x.x (RECOMMENDED) and 0.9.x (DEPRECATED). - `type` 'Catalog', required - `id` string, required — Identifier for the service. This field originates from STAC and is used as unique identifier for the STAC catalog available at `/collections`. - `title` string, required — The name of the service. - `description` string, commonmark, required — A description of the service, which allows the service provider to introduce the user to its service. [CommonMark 0.29](http://commonmark.org/) syntax MAY be used for rich text representation. - `conformsTo` string[], required — Lists all conformance classes specified in various standards that the implementation conforms to. Conformance classes are commonly used in all OGC API standards and the STAC API specification. The general openEO conformance class is `https://api.openeo.org/1.3.0`. See the individual openEO API extensions for their conformance classes. - `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. - `endpoints` object[], required — Lists all supported endpoints. Supported are all endpoints, which are implemented, return usually a 2XX or 3XX HTTP status code and are fully compatible to the API specification. An entry for this endpoint (path `/` with method `GET`) SHOULD NOT be listed. Each path MUST only be listed once in the array. - `path` string, required — Path to the endpoint, relative to the URL of this endpoint. In general the paths MUST follow the paths specified in the openAPI specification as closely as possible. Therefore, paths MUST be prepended with a leading slash, but MUST NOT contain a trailing slash. Variables in the paths MUST be placed in curly braces and follow the parameter names in the openAPI specification, e.g. `{job_id}`. - `methods` string[], required — Supported HTTP verbs in uppercase. It is OPTIONAL to list `OPTIONS` as method (see the [CORS section](#section/Cross-Origin-Resource-Sharing-(CORS))). - `billing` object — Billing related data, e.g. the currency used or available plans to process jobs. This property MUST be specified if the back-end uses any billing related API functionalities, e.g. budgeting or estimates. The absence of this property does not mean the back-end is necessarily free to use for all. Providers may choose to bill users outside of the API, e.g. with a monthly fee that is not depending on individual API interactions. - `currency` string, nullable, required — The currency the back-end is billing in. The currency MUST be either a valid currency code as defined in ISO-4217 or a back-end specific unit that is used for billing such as credits, tiles or CPU hours. If set to `null`, budget and costs are not supported by the back-end and users can not be charged. - `default_plan` string — Name of the plan the back-end uses for billing in case 1. the user has not subscribed to a specific plan (see `default_plan` in `GET /me`) and 2. also did not provide a specific plan with the processing request. If a free plan is available at the back-end, it is probably most useful to provide this as the back-end wide default plan and override it with paid plans through the user-specific default plan in `GET /me`. Otherwise, users that have not set up payment yet MAY receive an error for each processing requests where they did not provide a free plan specifically. - `plans` object[] — Array of plans - `name` string, required — Name of the plan. It MUST be accepted in a *case insensitive* manner throughout the API. - `description` string, commonmark, required — A description that gives a rough overview over the plan. [CommonMark 0.29](http://commonmark.org/) syntax MAY be used for rich text representation. - `paid` boolean, required — Indicates whether the plan is a paid plan (`true`) or a free plan (`false`). - `url` string, uri — URL to a web page with more details about the plan. - `links` Link[], required — Links related to this service, e.g. the homepage of the service provider or the terms of service. It is highly RECOMMENDED to provide links with the following `rel` (relation) types: 1. `version-history`: A link back to the Well-Known URL (including `/.well-known/openeo`, see the corresponding endpoint for details) to allow clients to work on the most recent version. 2. `terms-of-service`: A link to the terms of service. If a back-end provides a link to the terms of service, the clients MUST provide a way to read the terms of service and only connect to the back-end after the user agreed to them. The user interface MUST be designed in a way that the terms of service are not agreed to by default, i.e. the user MUST explicitly agree to them. 3. `privacy-policy`: A link to the privacy policy (GDPR). If a back-end provides a link to a privacy policy, the clients MUST provide a way to read the privacy policy and only connect to the back-end after the user agreed to them. The user interface MUST be designed in a way that the privacy policy is not agreed to by default, i.e. the user MUST explicitly agree to them. 4. `service-desc` or `service-doc`: A link to the API definition. Use `service-desc` for machine-readable API definition and `service-doc` for human-readable API definition. Required if full OGC API compatibility is desired. 5. `conformance`: A link to the Conformance declaration (see `/conformance`). Required if full OGC API compatibility is desired. 6. `data`: A link to the collections (see `/collections`). Required if full OGC API compatibility is desired. 7. `create-form`: A link to a user registration page. 8. `recovery-form`: A link to a page where a user can recover a user account (e.g. to reset the password or send a reminder about the username to the user's email account). 9. `web-editor`: A link to an openEO Web Editor instance. This allows clients to open a Web Editor for other tasks. It may be accompanied with a `version` flag in the link to allow feature-detection for certain Web Editor functionalities. For additional relation types see also the lists of [common relation types in openEO](#section/API-Principles/Web-Linking). - `rel` string, required — Relationship between the current document and the linked document. SHOULD be a [registered link relation type](https://www.iana.org/assignments/link-relations/link-relations.xml) whenever feasible. - `href` string, uri, required — The value MUST be a valid URL. - `type` string — The value MUST be a string that hints at the format used to represent data at the provided URI, preferably a media (MIME) type. - `title` string — Used as a human-readable label for a link. ## 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)