Two things worth knowing about how this is enforced, so you are not surprised by the failure mode:
- The reverse proxy in front of the CCF only checks that the `Authorization` header is present and syntactically looks like `Bearer <something>`; it does not validate the token itself. If the header is missing entirely, you get a `401` directly from the proxy (see [Errors](#errors)).
@@ -61,8 +65,6 @@ All parameters are optional; omitting all of them returns every published Servic
**Caveat on `api-versions` and `protocols`:** as of this writing, requesting more than one value for these two parameters returns only APIs that satisfy every listed value, rather than any one of them. Whether "any" or "all" is the intended semantics has not been confirmed against a project decision; treat this as current behaviour, not a guaranteed contract, until it is confirmed.
**Fixed 2026-08:**`api-names`, `api-ids`, `api-cats`, and `api-prov-names` previously returned no results at all (`404`) whenever more than one value was requested, because the values were combined as if an API had to match every one simultaneously — impossible for these single-valued attributes. This has been corrected so that a multi-value request returns any API matching at least one of the listed values.
## Errors
All error responses use the CAPIF `ProblemDetails` shape (`title`, `status`, `detail`, `cause`, and optionally `invalidParams`).
