Does the Remote Settings PROD API need an API key?

Does the Remote Settings PROD API need an API key?

It depends on the operation. Of those checked on 2026-09-15, 8 refused an anonymous request and 2 answered one. An API being partly open is exactly what a single security declaration cannot express.

ERR-2026-1675, ERR-2026-1676, ERR-2026-1688, ERR-2026-1694, ERR-2026-1698, ERR-2026-1700, ERR-2026-1704, ERR-2026-1710, ERR-2026-1679, ERR-2026-1709

Why does Remote Settings PROD return 401 when its spec declares no authentication?

Because the document is wrong about it. Its OpenAPI description declares no security requirement for 8 operations, and an anonymous request to each was refused with 401 on 2026-09-15. An agent trusting the document plans a call that cannot work.

ERR-2026-1675, ERR-2026-1676, ERR-2026-1688, ERR-2026-1694, ERR-2026-1698, ERR-2026-1700, ERR-2026-1704, ERR-2026-1710

Every record behind those answers

10 open records, observed 2026-09-10. Every claim below carries the command that disproves it. If one is wrong, it should be withdrawn — 121 have been across the whole registry.

the document declares no authentication and the API demands it (8)

The OpenAPI document declares no security requirement for this operation. An anonymous request is refused with 401. An agent trusting the document plans a call that cannot work.

ERR-2026-1675get_recordsHTTP 401checked 2026-09-15, 2 times
ERR-2026-1676get_collectionHTTP 401checked 2026-09-15, 2 times
ERR-2026-1688get_groupHTTP 401checked 2026-09-15, 2 times
ERR-2026-1694get_groupsHTTP 401checked 2026-09-15, 2 times
ERR-2026-1698get_bucketHTTP 401checked 2026-09-15, 2 times
ERR-2026-1700get_collectionsHTTP 401checked 2026-09-15, 2 times
ERR-2026-1704get_recordHTTP 401checked 2026-09-15, 2 times
ERR-2026-1710get_collection-changesetHTTP 401checked 2026-09-15, 2 times

Check it yourself:

curl -sS -o /dev/null -w '%{http_code}\n' https://firefox.settings.services.mozilla.com/v1/buckets/errata-probe-not-a-real-identifier/collections/errata-probe-not-a-real-identifier/records

usable with no account (observed) (2)

An anonymous request is answered with a machine-readable response. The operation is reachable with no account. This says nothing about whether the result is useful, or about rate limits.

ERR-2026-1679server_infoHTTP 200checked 2026-09-15, 2 times
ERR-2026-1709get_bucketsHTTP 200checked 2026-09-15, 2 times

Check it yourself:

curl -sS -o /dev/null -w '%{http_code}\n' https://firefox.settings.services.mozilla.com/v1/

Also filed as: mozilla.com, mozilla.com:kinto. One page, because two sweeps named the same subject differently and the record that mattered was on the page nobody would open.

If a record here is wrong

Run its check. If the answer differs from what is written, say so here and it will be withdrawn — 121 already have been. A record nobody can contest is a record asking to be trusted, which is the opposite of the point.

What this page does not tell you

This is not a clean bill of health for anything not listed. The registry was built from a sample of two directories, and an operation absent from it was almost certainly never examined. Silence here means not looked at, not looked at and fine — which is the same mistake this registry exists to record in other people.

What this is

A record of defects in the public description of machine-callable operations: documents a directory claims are live and are not, hosts that no longer resolve, specifications that contradict the API they describe. It is not a ranking, not a review, and not a judgement about the service. No credential is ever sent to anything listed here.

The whole registry, machine-readable: errata.json. Index of subjects: index.html.

Built from registry errata-2026-09-10@b7cb54d3a847. If manifest.json shows a different one, this page is behind the records and should not be trusted over them.