In July 2026, while debugging pygeovision's Copernicus download path, we encountered a consistent HTTP 422 Unprocessable Entity response on what appeared to be valid product UUIDs. The error message from Copernicus was {"code":"DAT-ZIP-111","message":"Invalid uuid as ID parameter"}. But the UUIDs looked valid and had been returned by the search API moments earlier.

The Root Cause

The Copernicus Data Space STAC catalog (catalogue.dataspace.copernicus.eu/stac) indexes two variants of every Sentinel-1 GRD product in the sentinel-1-grd collection:

• Standard SAFE packages: S1A_IW_GRDH_1SDV_....SAFE — downloadable via Products('UUID')/$value with a Bearer token
• COG reformats: S1A_IW_GRDH_1SDV_..._COG.SAFE — stored on S3, accessible via the eodata.dataspace.copernicus.eu S3-compatible endpoint, NOT via OData

The STAC search returns both variants. When the COG product is selected and its UUID is passed to the OData download endpoint, Copernicus returns 422 because the OData system does not recognise the COG UUID.

The Fix

Add not endswith(Name, '_COG.SAFE') to the OData $filter parameter. This ensures the search returns only standard SAFE products that the download endpoint actually handles:

filters.append("not endswith(Name, '_COG.SAFE')")

This single filter addition resolved all 422 errors in our testing. The fix is now in the PyGeoFetch Copernicus provider (pygeofetch/providers/copernicus.py) as part of our integration audit contributions.

Lessons

The Copernicus ecosystem has two parallel APIs — STAC and OData — with subtly different product namespaces. COG products exist to make cloud-native partial reads efficient via the s3://eodata endpoint. They are not designed for bulk download via OData. When building download pipelines, always use sentinel-1-grd collection with the COG exclusion filter for OData access.