Add the Multi-Tenant Catalogs Endpoint Extension, for nested catalog support

[jonhealy1]

Related Issue(s):

• Implementing the Multi-Tenant Virtual Catalogs STAC API Extension #376
• Nested catalogs in stac-fastapi-pgstac #79
• Multi-tenant /Catalogs Extension stac-fastapi#880
• Hierarchically organized STAC APIs pgstac#88

Description:

Extension spec: https://github.com/StacLabs/multi-tenant-catalogs
STAC-FastAPI catalogs extension: https://github.com/StacLabs/stac-fastapi-catalogs-extension

PR Checklist:

• pre-commit hooks pass locally
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
• Changes are added to the CHANGELOG.

[jonhealy1]

It's going to be best to fix the extension so it supports python 3.11

[jonhealy1]

This is really close to being reviewable, just need some time to do some qa, documentation.

[bkanuka]

When parent_ids are added to a collection, all parent_ids are present, not just parents in the current catalog "tree".

For example:

GET http://localhost:8080/catalogs/new_catalog_2/collections/gov-tabular-datasets

HTTP/1.1 200 OK
date: Fri, 01 May 2026 22:33:30 GMT
server: uvicorn
content-length: 328
content-type: application/json
content-encoding: br
vary: Accept-Encoding

{
  "id": "gov-tabular-datasets",
  "type": "Collection",
  "links": [],
  "title": "Government Tabular Datasets",
  "extent": {
    "spatial": {
      "bbox": [
        [
          -180,
          -90,
          180,
          90
        ]
      ]
    },
    "temporal": {
      "interval": [
        [
          "2020-01-01T00:00:00Z",
          null
        ]
      ]
    }
  },
  "license": "public-domain",
  "keywords": [
    "tabular",
    "parquet",
    "government",
    "open-data"
  ],
  "parent_ids": [
    "new_catalog",
    "new_catalog_2"
  ],
  "description": "Government tabular datasets available as Apache Parquet files, including property parcels, county boundaries, water bodies, and other administrative data.",
  "stac_version": "1.0.0"
}

In my use case I wanted to use catalogs as access controls for collections. Eg /catalogs/username/collections would list collections that the user has access to. /catalogs/username/* routes are protected via a middleware. With all parent_ids listed, this allows a user to deduce other usernames and permissions, which is a bit of a security issue.

Not sure sure if this behavior is to spec and expected, or specific to this implementation.

[bkanuka]

Another issue - the self link for a Collection does not include the col_id when accessed via catalogs/{catalog_id}/collections. Eg

GET http://localhost:8080/catalogs/new_catalog_2/collections

{
  "collections": [
    {
      "id": "gov-tabular-datasets",
      "type": "Collection",
      "links": [
        {
          "rel": "self",
          "type": "application/json",
          "href": "http://localhost:8080/catalogs/new_catalog_2/collections"
        },
...snip

The href should be http://localhost:8080/catalogs/new_catalog_2/collections/gov-tabular-datasets

[jonhealy1]

When parent_ids are added to a collection, all parent_ids are present, not just parents in the current catalog "tree".

For example:

@bkanuka There is a glitch here, that needs to be fixed. The parent_ids list should not be returned to the client via an API response. The parent_ids list should only be present in Postgres.

[jonhealy1]

@bkanuka Thanks for the feedback. I have implemented the two suggestions you made. Removing parent_ids from collection responses and fixing/ improving the self link generation.

[vincentsarago]

ENABLE_CATALOGS_ROUTE -> ENABLE_CATALOGS_ROUTES ?

[jonhealy1]

I would prefer singular. It matches what we use if SFEOS. Everything starts from /catalogs so it makes some sense. I think both variations make sense.

[jonhealy1]

I am good with changing it also.

[jonhealy1]

@vincentsarago Thanks for reviewing. I have implemented most of your suggestions - except for the name change.

I have also updated the catalogs extension to v0.2.0 which basically just means a separate catalogs transactions class. My thinking is that the catalogs transaction routes will only be implemented when the core transaction extension is enabled. This may be too simplistic, let me know what you think.

Additionally I added some documentation to the readme and settings.md.