---
title: "Supported file formats"
method: GET
path: "/file_formats"
tags: ["Capabilities", "Data Processing"]
---

# Supported file formats

`GET /file_formats`

Lists supported input and output file formats.
*Input* file formats specify which file a back-end can *read* from.
*Output* file formats specify which file a back-end can *write* to.

The response to this request is an object listing all available input
and output file formats separately with their parameters and additional
data. This endpoint does not include the supported secondary web
services.

**Note**: Format names and parameters MUST be fully aligned with the
GDAL codes if available, see [GDAL Raster
Formats](https://gdal.org/drivers/raster/index.html) and [OGR Vector
Formats](https://gdal.org/drivers/vector/index.html). It is OPTIONAL to
support all output format parameters supported by GDAL. Some file
formats not available through GDAL may be defined centrally for openEO.
Custom file formats or parameters MAY be defined.

The format descriptions MUST describe how the file formats relate to 
data cubes. Input file formats MUST describe how the files have to be
structured to be transformed into data cubes. Output file formats MUST
describe how the data cubes are stored at the back-end and how the 
resulting file structure looks like.

Back-ends MUST NOT support aliases, for example it is not allowed to
support `geotiff` instead of `gtiff`. Nevertheless, openEO Clients MAY
translate user input for convenience (e.g. translate `geotiff` to
`gtiff`). Also, for a better user experience the back-end can specify a
`title`.

Format names MUST be accepted in a *case insensitive* manner throughout the API.

## Response `200`

An object with containing all input and output format separately.  For each property `input` and `output` an object is defined where the  file format names are the property keys and the property values are objects that define a title, supported parameters and related links.

- object
  - `input` object, required — Map of supported input file formats, i.e. file formats a back-end can **read** from. The property keys are the file format names that are used by clients and users, for example in process graphs.
  - `output` object, required — Map of supported output file formats, i.e. file formats a back-end can **write** to. The property keys are the file format names that are used by clients and users, for example in process graphs.

## 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)