Changelog
What changed in the SIDES LABS API
The API is a contract. Adding a field, an endpoint or an enum value is something you will find here; removing, renaming or re-typing one is something that needs a new major version and six months of notice. This page is where both are recorded, in the order they were released.
The entries
Released changes, newest first
Rendered from GET /v1/publication/public/changelog-entries. An entry
appears here only once SIDES has released it — a pipeline that pushes one creates
a draft, and a draft is not a changelog.
No entries yet
Nothing has been released to the public changelog so far. Every release writes an entry, so this fills up with the first one.
How to read an entry
Six kinds, and only two of them ask anything of you
Every entry carries one of these. They are not severities and they are not ordered — they say what happened, and two of them mean there is a date you should know about.
- Added
- A new endpoint, field, enum value or header. Nothing you already send or parse changes. A client that ignores unknown fields — which the contract asks every client to do — needs no work at all.
- Changed
- Behaviour that moved without breaking the contract: a default, a limit, an ordering, an error message. The shape is the same; what comes back may not be.
- Deprecated
-
Still there, still working, and on notice. A deprecation entry carries a
sunset date and the API sends the same date in the
X-SIDES-Deprecationheader on every response from the endpoint it concerns. This is the entry to act on, and you have at least six months. - Removed
- Gone, and only ever in a new major version. Nothing is removed from a version that is in force — that is what "the API is a contract" means in practice.
- Fixed
- The API was not doing what this specification said it did, and now it is. If you worked around the old behaviour, this is the entry that tells you the workaround can go.
- Security
- A security-relevant change. It is published once it is deployed, never before, and it says what class of problem was closed without handing anybody a recipe for reproducing it.
Questions
Before you ask us
Is everything here, or only what SIDES chose to mention?
Every release writes an entry — that is a rule in the delivery standard, not a habit. What this page does not show is entries whose audience is partner rather than the open internet: those reach a signed-in partner and are never in this feed. The distinction is the entry's, not the reader's, and nothing you can send to this endpoint changes it.
Can I get this without opening a browser?
Yes. The same entries are an Atom 1.0 feed, with the same filters as this page,
and every entry id is stable across a withdrawal and a re-release — so a reader
that has already shown you an entry will not show it again because SIDES
corrected a typo. The feed lives at /changelog.atom here; the
same entries are GET /v1/publication/public/changelog-entries on
the API as JSON, which needs the storefront scope — any
registered client may ask for it and is granted it.
Why does an entry list endpoints?
So you can tell in one line whether a change is yours to care about. An entry names the API it concerns, the version it was released in, and the endpoints it touches, spelled the way this specification spells them — template segments included. A change to an endpoint you do not call is a change you can skip.
My pipeline wants to push its own entries. Can it?
That is what the ingestion API is for:
POST /v1/publication/changelog-entries under
publication.changelog:write, idempotent on your own reference, so
re-running the job does not create a second entry. It creates a draft; releasing
it stays a deliberate act. The tier your partnership is on says whether the
capability is included.
Build against a contract with advance notice
No breaking change without a new major version and six months of notice, every deprecation dated in the response header as well as on this page, and an ingestion API so your own releases can appear here too.
