Adding apiVersion causing breaks in Sanity code

12 replies
Last updated: Jul 7, 2022
Hey everyone, glad to be in this slack!
We make heavy use of Sanity for work.

We have still been using the Sanity version without setting an apiVersion. So I added that and now I am getting some breaks in the code.

I haven't had much success finding out why adding an apiVersion would break current queries but maybe someone here has experienced this and could point me in the right direction?
AI Update

Welcome to the community! This is a common issue when adding an apiVersion for the first time. Let me help you understand what's happening.

When you don't set an apiVersion, Sanity's client defaults to v1 of the API. Once you add an explicit apiVersion (like '2021-03-25' or later), you're upgrading to a newer version that includes several breaking changes.

What Changed Between v1 and Later Versions

According to the official API versioning documentation and GROQ changelog, the most significant breaking changes when moving from v1 to v2021-03-25 include:

1. Correct parent operator (^) behavior

The ^ operator now works correctly in all scopes. Previously in v1, it had buggy behavior where it would return the root of the current scope instead of the parent scope in certain contexts.

2. Three-valued logic for null/undefined handling

The handling of null and undefined values changed significantly. The == operator now always returns true or false (never null), and comparison operators like >, >=, <, <= return null when operands are of different types. This is probably what you're experiencing with properties returning null instead of arrays.

3. Null values are no longer removed in projections

If you have stored null values in your documents, these are no longer automatically removed in projections in newer API versions.

4. Array traversal behavior

Multiple array traversals now work more consistently and correctly.

How to Debug and Migrate

  1. You can stay on v1 temporarily - Use apiVersion: 1 or apiVersion: 'v1' to explicitly use the old version while you work through issues
  2. Test queries individually - Migrate one query at a time rather than everything at once
  3. Check for null handling - Based on what you described (properties being arrays in v1 but null with apiVersion set), you likely have queries that need to handle null values differently
  4. Use the changelog filters to see exactly what changed between versions

Working Around the Null Issue

As mentioned in the community answers, one workaround is to use conditional checks in your GROQ queries:

defined(field) => {field}

This ensures fields are only included when they're defined, though it can be tedious to add everywhere.

The good news is that while these are breaking changes, they generally fix bugs and make GROQ more predictable and spec-compliant. Once you update your queries, they'll be more robust going forward. And there's no rush - v1 will continue to be supported for the foreseeable future, though it won't receive new features.

Unless something's changed, the docs suggest that the absence of indicating an API version makes it assume a value of 'v1' which it also indicates was the first .
Because it's date-based, the only thing I can think of as far as a point of reference to when changes happened is using the
changelog and the filters on the side to see when relevant/breaking parts of your query changed and whatever might bring them back into alignment.
So the behavior that is happening right now is that without an apiVersion set the property is set to an array of objects
With an apiVersion set the property is sent back as null
Can you show your query?
As Vincent mentioned, omitting the apiVersion will cause the client to use
v1
of the API. You should be able to specify
apiVersion: 1
when configuring to remove the warning, but eventually will want to migrate to a later version as there have been several improvements. Kitty’s suggestion to post the query would be a big help, but if you're using `@`/`^` those have changed behaviours between
v1
and later.
user F
I apologize for not responding sooner. I spoke to work and they didn't want me to share the query since it is business logic related.
However, after seeing
user A
's response, I am wondering if I am setting the apiVersion correctly.
Is the apiVersion supposed to be a date? Or is it an actual version? I was under the impression that it was a date string. But reading above makes it seem like it could be v1 v2.02....something like that.
If we’re talking about configuring the JS client to use an API version, the version will either be
1
or a date &gt;=
2021-03-25
. There’s no
v2.02
, etc., and I believe the
v
is optional. More details are here .
Using the HTTP API, the same rules apply but the
v
is mandatory.
user A
idk the best way to ask this but I guess my simple question is, will version 1 of the api be deprecated in the future?
Or is there a plan for longterm support for certain older versions?

Thanks!
There’s no plan I’m aware of to deprecate
v1
soon. That said, it won’t have new features added to it, so there may come a point when it’s not possible to run
v1
with the Studio release of the time. When it is deprecated, it will be done in accordance with the process we’ve laid out .
Our approach has always been to make as few breaking changes as possible, and when we have to do so, to put plenty of thought and consultation into it.
v1
remains the “default” in the client and many people and customers still use it.
Thanks! I was trying to migrate everything for work over to a updated apiVersion and I think I am going to go a slower route. We use Zod for validation on what is returned from Sanity so Im gonna start there an then have validation set up so that when we start moving to a newer version it is much less of tons of changes.
The biggest thing I was running into was what gets ignored or is undefined in v1 is now null in newer versions.
Sounds good! The `null`/`undefined` issue you mentioned is being considered internally. I don’t know its status but it’s certainly on our radar .
There are workarounds if you’re interested, but it involves a conditional check on every field (if I recall correctly) so probably more work than it’s worth.
Edit: The check is
defined(field) => {field}
in your GROQ query.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?