openEO Back-End Extractor

A generic "point at any openEO back-end" extractor. openEO is the open, uniform REST API for Earth-observation cloud back-ends — the standard that lets one client talk to VITO/Terrascope, the Copernicus Data Space Ecosystem, EODC and every other openEO-conformant processing back-end the same way, over satellite data cubes (Sentinel-1/2/3, Landsat, and hundreds of derived collections).

Because the grammar is uniform across operators, one actor spans them all. Point it at a back-end URL, pick a read mode, and it flattens that back-end's public discovery documents into clean tabular rows — with the same normalized shape regardless of the operator — plus a lossless raw copy of every record. No per-operator scraper, no authentication.

How it resolves a back-end

openEO back-ends advertise themselves at {host}/.well-known/openeo — a list of API versions, each with a production flag and a versioned base URL. Give the actor the host root (e.g. https://openeo.vito.be) and it resolves the well-known document to the highest production version base for you, then reads the core discovery endpoints against it. You can also pass an already-versioned base (e.g. https://openeo.terrascope.be/openeo/1.2) and skip that step, or pin a specific version with apiVersion.

Seven read modes

Mode	What you get (one flat row per…)
collections (default)	…EO data collection (STAC-flavored) — id, title, description, license, keywords, extentSpatial (bbox), extentTemporal (interval), providers, raw
processes	…process in the back-end's registry — id, title (summary), categories, parameterCount, parameters, returns, deprecated, experimental, raw
capabilities	the landing document (id, title, api/backend/stac versions, production, advertised endpoints) plus one row per advertised API version
collection-detail	…requested collection id — the full STAC Collection incl. cubeDimensions, summaries, providers, extents
file-formats	…supported input and output file format — id, direction, title, gisDataTypes
service-types	…secondary web service type the back-end can publish (WMTS/XYZ/…). Optional in the spec — processing-only back-ends have none.
udf-runtimes	…user-defined-function runtime (Python/R/…) — id, runtime url (type), available versions in keywords

Every row also carries provenance (_backend, _mode, _type) and the lossless raw source object.

Input

{
  "backend": "https://openeo.dataspace.copernicus.eu",
  "mode": "collections",
  "collectionId": [],
  "maxItems": 10000
}

• backend (required) — the URL of any openEO back-end. Host root preferred (the actor resolves /.well-known/openeo); a versioned base also works.
• mode — one of the seven above. Default collections.
• collectionId — only used by collection-detail mode; the collection id(s) to fetch full detail for. Run collections first to discover the exact ids.
• apiVersion — optionally pin the openEO API version (e.g. 1.2.0); defaults to the highest production version advertised.
• maxItems — total row cap (each row is one billable event). Default 10000.
• bearerToken / extraHeaders — optional; not required — every read mode targets public, unauthenticated discovery endpoints. Never logged.

Output (collections mode, example row)

{
  "_backend": "https://openeo.dataspace.copernicus.eu/openeo/1.2",
  "_mode": "collections",
  "_type": "collection",
  "id": "SENTINEL3_OLCI_L1B",
  "title": "Sentinel 3 OLCI",
  "license": "proprietary",
  "keywords": null,
  "extentSpatial": [[-180.0, -85.0, 180.0, 85.0]],
  "extentTemporal": [["2016-04-17T11:33:13Z", null]],
  "stacVersion": "1.0.0",
  "raw": { "…": "the full STAC Collection" }
}

Behaviour & honesty

• Version resolution is automatic. The well-known document is parsed to the best production version base; an already-versioned base is used as-is.
• STAC collections are flattened (id/title/description/license/extents) with the full STAC Collection preserved in raw — nothing is lost.
• Pagination handled. collections and processes auto-follow the top-level rel="next" link (relative or absolute) until exhausted or the cap is reached.
• Optional endpoints degrade gracefully. service_types / udf_runtimes are optional in the openEO spec; a back-end that doesn't offer one is reported, not crashed.
• Zero records is never faked. If the chosen mode returns nothing (an optional endpoint the back-end doesn't serve, or an unknown collection id), the run exits non-zero instead of emitting fabricated rows.

Pricing

Pay-per-event: one record charge per row returned.

Verified

Tested live against three independent operators — VITO/Terrascope (openeo.vito.be → 89 collections / 150 processes), Copernicus Data Space Ecosystem (openeo.dataspace.copernicus.eu → 83 / 143) and EODC (openeo.eodc.eu) — confirming identical normalized output across back-ends.