Auto-generated IDs with hyphens fail on team type but underscores work

9 replies
Last updated: Jan 28, 2026
Odd one. I’m doing a data import and auto-generating ID’s so I can create ref’s on the fly.
This returns a bad request

[ { createOrReplace: { _type: "team", _id: "team-67" } } ]
This imported fine (underscore in
_id
string)
[ { createOrReplace: { _type: "team", _id: "team_67" } } ]
Stranger still, it didn’t have the same issues with
teamMember-123
or
office-456
, only on this
team-
type.
(This is via the HTTP mutations API)
AI Update

This is a genuinely puzzling issue, and I need to be honest: I cannot find documentation that definitively explains why team-67 specifically fails while other similar patterns work.

Based on the official Sanity documentation on document IDs, the documented rules are:

  • Maximum 128 characters
  • Can only contain a-zA-Z0-9._-
  • Cannot start with a - (dash)
  • Must not have more than one consecutive . character
  • Avoid prefixes like drafts. and versions. (used internally)

According to these rules, team-67 should be valid—it doesn't start with a dash, contains only allowed characters, and doesn't use reserved prefixes.

What's particularly strange about your situation:

  • team-67 fails ❌
  • team_67 works ✅
  • teamMember-123 works ✅
  • office-456 works ✅

This inconsistency suggests there might be:

  1. An undocumented validation rule specific to certain ID patterns
  2. A bug in the HTTP mutations API validation
  3. Some internal pattern matching that isn't publicly documented

My recommendations for moving forward:

Immediate fix: Use underscores instead of dashes in your auto-generated IDs since you've confirmed team_67 works. This is the quickest way to unblock your import.

Better long-term approach: Consider using a custom field for your identifiers rather than controlling _id. As the documentation recommends, create a customId field in your schema and let Sanity generate the _id:

{
  name: 'team',
  type: 'document',
  fields: [
    {
      name: 'teamId',
      type: 'string',
      validation: Rule => Rule.required()
    }
  ]
}

Get a definitive answer: Since this behavior contradicts the documented rules, I'd recommend contacting Sanity support directly with your specific examples. They should be able to explain whether this is a bug or an undocumented validation rule.

You can also test systematically by trying IDs like team-1, team-2, team-a, etc. to see if there's a specific pattern to the failures—this data would be valuable for a support ticket.

Show original thread
9 replies

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?