Add usage log entry operations to Public API

[ajwild]

• Added addUsageLogEntry, updateUsageLogEntry and removeUsageLogEntry operations to media library patch endpoint of the Public API
• Updated the technical release notes for release-2026-05
• Added an entry into the Public API changelog
• Fixed some invalid OpenAPI schema definitions so that the file will open again!

[robinbisping]

There is an additional file that probably should be updated: /reference/public-api/changelog/

[robinbisping]

The preserveUpdatedAt parameter is only available in API versions 2026-03 and newer. Deleting this file makes it now appear as if it were available for all API versions.

It's different from the {{< added-in "release-2026-03" block >}} tag, which are about the release not the API version.

I would restore the file, what do you think? 🤔

[ajwild]

Wouldn't that mean that (almost) every time we have a changelog entry we should also have a new page? I don't think we've done it this way previously, although I'm not against it. Should I open another PR to add more versions?

[robinbisping]

Maybe @marcbachmann can explain his intention ones again. I'm not sure. My understanding is that functionality restricted to certain API versions should only appear in the docs for these API versions (e.g. preserveUpdatedAt). On the other hand, features added to all API versions (e.g. the new usage log commands) don't require new pages.

[marcbachmann]

Yes, every release that got an addition needs to be new yaml declaration. And the apiVersionConstraints should be aligned.

So basically copy the file without release postfix in the name to the older release till it was valid and change the apiVersionConstaints to fit the ranges.

[ajwild]

Thank you both for explaining. I've restored the file.

One thing I haven't been doing is editing the old endpoint data. I only touch the one without the release suffix. Should I be adding the changes I've made in data/endpoints/patch-media-library-entry.yaml to patch-media-library-entry-2026-01.yaml as well? Technically these changes are available in the v1 and beta endpoints, even if they would not work unless you're on release-2026-05 or above.

[robinbisping]

I would add them to both API version files and tag them with an {{< added-in "release-2026-05" >}} shortcode.