# A content publish broke our prod build, was it because we did not pin the slot version?

Asked by Wesley Adkins on 2026-08-28. Tags: nextjs, slots, versioning.

Someone on the content side published a schema change to a slot and our Next
app immediately started getting content that did not match our types. Here is
what I checked so far:

- the deploy that broke was not ours, no code changed
- the timing lines up exactly with the publish
- we fetch the slot without a version in the ID

My theory is that the missing version is the whole problem. Can someone confirm
the safe practice before this bites us again

## 2 answers

### Accepted answer from Ingrid Bakker (2026-08-29)

Your theory is correct. When you omit the version in the slot ID it resolves
to `@latest`, so the moment a schema change is published it takes effect on
your live app, and if your code expected the old shape it breaks. Nothing on
your side needs to deploy for it to happen.

The safe default is to pin a versioned slot ID, for example `'home-hero@2'`,
either major or major.minor. Old versions keep serving after a schema change,
so a pinned app keeps getting the shape it was written against until you
deliberately bump the version and update the code together. In our case we
pin everything and treat the version bump as part of the pull request that
handles the new schema.

#### Reply from Wesley Adkins (2026-08-30)

Pinned every slot ID this morning and it is stable now. Publishing on
their side no longer touches us until we bump. Thanks

### Answer from devon_l (2026-08-30)

worth adding one related gotcha now that you are pinning, preview links also
require the slot version to match. if you pin to @2 in code but the preview is
built against a different version you get default content in the widget and
think something is broken. more on that in
[this preview shows default content thread](/answers/nextjs-preview-link-shows-default-content)