Studio

Email

Schema type reference for the email type.

A string which represents an email address. Every email field checks that its value is a valid email address, with no validation configuration needed. See the EmailDefinition reference for the full type definition.

Properties

  • Requiredtype

    Value must be set to email.

  • Requiredname

    The field name. This becomes the key in the document.

  • Human-readable label for the field.

  • If set to true, this field is hidden in the studio. You can also supply a callback function to make it a conditional field.

  • If set to true, this field is not editable in the studio. You can also supply a callback function to make it a conditional field.

  • Short description for editors of how the field is to be used.

  • The initial value used when creating new values of this type. Can be a literal value, or a resolver function that returns a literal value or a promise that resolves to one.

  • Lets you provide custom components to override the studio defaults in various contexts. The available keys are diff, field, input, item, and preview.

  • Marks a field or document type as deprecated in the studio interface and displays a user-defined message set through the single required reason property.

    If you deploy a GraphQL API schema, this property is translated into the @deprecated directive.

  • Supply a custom icon for this field. See the icons documentation for more information.

  • Placeholder text shown in the input when it has no value.

Options

The email type has no options of its own. Only the shared options below apply. See the EmailOptions reference for the full type definition.

  • Configures how Sanity Create interfaces with this field. Set exclude: true to leave the field out of Sanity Create, or purpose to describe what the field holds so that content mapping can use it.

  • Configures how Canvas interfaces with this field. Takes the same exclude and purpose properties as sanityCreate.

Validation

Every email field is validated as an email address even when you set no validation of your own. An invalid value fails with Must be a valid email address. Rules you chain are added to that check rather than replacing it, so rule.required() enforces presence and format together. Only skip() removes the format check. See the EmailRule reference for the full type definition.

  • Ensures that this field exists.

  • Discards the validation rules set before it in the chain and makes the field optional. Rules chained after it still apply.

  • Creates a custom validation rule.

  • Sets a custom error message for the preceding validation rule.

  • Sets a custom warning message for the preceding validation rule. Warnings do not prevent publishing.

  • Sets a custom info message for the preceding validation rule. Info messages are purely informational and do not prevent publishing.

  • Gets the value of a sibling field to use in validation. Useful for creating validation rules that depend on the value of another field.

The email type and the email() validation rule are different things

The email type stores a string and renders a single-line text input. That input always carries type="email" and inputMode="email", so the browser applies its own email validation and mobile keyboards show the email layout.

<input type="email" inputmode="email">

Input

Response

{
  "_type": "author",
  "contactEmail": "editor@example.com",
  ...
}

To make an email address mandatory and hint at the expected format, combine required() with placeholder:

Was this page helpful?