Changelog

The policy is not in force yet

Read this before the policy below, because the two would otherwise look inconsistent. This specification is still changing, sometimes in ways that would be breaking under the definition below, and no notice is being given for any of it. That is not the policy being ignored; it is the policy not having started.

Art. 30(4) protects integrations. There are none: nothing here has ever served a provider, so no correct integration exists that a change could break. Giving three months’ notice of a correction to a document nobody has built against would teach you to discount the notices that will matter.

The policy below binds us from the first entry in Releases, which will be go-live. Until that entry appears, treat this specification as a moving target, pin nothing, and re-read before you cut over. After it appears, every breaking change gets its three months.

Our change policy

Breaking changes to this interface are published at least three months before they take effect (RTS 2018/389 Art. 30(4)). A breaking change means anything that could make a correct integration stop working: a removed endpoint, a removed or renamed field, a narrower accepted input, a new required header, or a change to the Berlin Group specification version we implement.

Non-breaking additions — a new optional field, a new endpoint, clarified prose — ship without notice and are recorded here.

The exception is a security fix, which may ship immediately. When that happens we document it here afterwards and explain why the notice period was not observed.

Subscribe to changes via support.

Releases

None yet. The first entry will name the date the production host starts answering. Until then the specification and the sandbox may change without notice — nothing has served a provider, so there is no integration a change could break.