# A process for specifying the subgraph API version and feature support matrix

**URL:** <https://forum.thegraph.com/t/a-process-for-specifying-the-subgraph-api-version-and-feature-support-matrix/2004>\
**Category:** Graph Improvement Proposals (GIP)\
**Tags:** protocol-gov\
**Created:** [May 15, 2021, 12:52am UTC](https://forum.thegraph.com/t/a-process-for-specifying-the-subgraph-api-version-and-feature-support-matrix/2004 "2021-05-15T00:52:43Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![adamfuller](https://avatars.discourse-cdn.com/v4/letter/a/8e8cbc/32.png) [@adamfuller](https://forum.thegraph.com/u/adamfuller)\
**Post date:** [November 27, 2021, 2:24pm UTC](https://forum.thegraph.com/t/a-process-for-specifying-the-subgraph-api-version-and-feature-support-matrix/2004/8 "2021-11-27T14:24:53Z")

</div>

> [@Brandon](#):
>
> Also agree that the Consumer should be able to specify a version to be used in a query, so that the Indexer can respond w/ the proper domain separator.

> [@That3Percent](#):
>
> The Indexer can answer queries for ranges of protocol versions with backward compatible code all the way to version 0 and there is no fundamental reason to deprecate N-1 versions (possibly ever)

To clarify the implications of this approach as I understand them - Graph Node would need to introduce graphQL API versioning (currently there is only the latest), and the ability to answer queries for historical versions as well as the latest. That versioning could be indicated in the URL:

```auto
https://gateway.thegraph.com/api/[api-version]/[api-key]/subgraphs/id/[identifier]

```

Any feature that changed the graphQL API would require a version bump (even if it is simple addition of a field).

This pattern (for prior version compatibility) exists already in Graph Node for the mapping apiVersion. It would add complexity in Graph Node’s graphQL implementation, and may have some operational or performance implications (I have not fully investigated this). And this would not be about conforming with graphQL compatibility (which allows for simple additive changes), but protocol compatibility.

Let me know if you have a simpler implementation in mind @Brandon and @That3Percent . This does not seem too onerous, and would seem to simplify the situation by creating entirely deterministic query responses. But would be great to clarify if this is a requirement ASAP, given in-progress and planned changes to the graphQL API.

---

_[View the full topic](https://forum.thegraph.com/t/a-process-for-specifying-the-subgraph-api-version-and-feature-support-matrix/2004)._