# Negotiating reconciliation API versions

**URL:** <https://forum.openrefine.org/t/negotiating-reconciliation-api-versions/2250>\
**Category:** Development & Design\
**Tags:** reconciliation\
**Created:** [April 17, 2025, 1:06pm UTC](https://forum.openrefine.org/t/negotiating-reconciliation-api-versions/2250 "2025-04-17T13:06:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![abbe98](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/abbe98/32/1299_2.png) [@abbe98](https://forum.openrefine.org/u/abbe98)\
**Post date:** [April 17, 2025, 1:06pm UTC](https://forum.openrefine.org/t/negotiating-reconciliation-api-versions/2250/1 "2025-04-17T13:06:52Z")

</div>

Hi all,

We are currently moving our clients to a `1.0-draft` variant of the reconciliation specification, however, for our services to remain compatible with [OpenRefine.org](http://OpenRefine.org) we will keep supporting `0.2` for the time being.

To achieve this we intend to make it so that our clients supporting `1.0-draft` will explicitly ask for that version. This means that to support [OpenRefine.org](http://OpenRefine.org) our default will need to be `0.2` although we will consider that version the legacy one. This could however, be much improved if version negotiation would become a part of the specification and later supported in [OpenRefine.org](http://OpenRefine.org).

Because of this I would like to draw some attention towards the following issue regarding version negotiation in reconciliation services, with the hope that others are interested in moving this particular issue forward:

> <https://github.com/reconciliation-api/specs/issues/78>
>
> It looks like the API version here doesn't change much, but I'm not clear what t…he semantics are when the API does change. As mentioned \[here\](https://github.com/reconciliation-api/specs/pull/67#issuecomment-968246070) the \[service manifest\](https://reconciliation-api.github.io/specs/latest/#service-manifest) includes a list of versions the server can support, but it's not clear what that means.
> 
> Is the client expected, to pick from among those versions? Does the client fail when it can't support any of those versions? If the server supports multiple versions, how does the client communicate that to the server? What exactly is the handshake mechanism?
> 
> Again, this doesn't seem urgent as the API version doesn't change much but having a well defined plan could help in figuring out what risks there are to a given change and mapping out a rollout of added features.