Variants
A record can serve different content to different audiences: a whole alternative version, one field, or one paragraph. The server chooses which variant a request gets, using targeting rules you define once and reuse.
Record, field and entry
On a model with variants switched on, a record has a default and can have several variants. A record-level variant replaces the whole record's content and has its own publishing state and version history. A field-level variant overrides one field for an audience and leaves the rest of the record as it is. Inside a prose field or a list, a single entry or item can vary by itself.
Targeting comes from the catalogue
Who a variant is for is set by a variant catalogue entry: a named, reusable set of targeting rules with a priority. Editing an entry retargets every variant that references it. The rules read context dimensions and segments.
How the server chooses
Every variant's rules are evaluated against the request, and of those that match, the one with the highest catalogue priority wins. A tie goes to the record's default variant. When no variant may serve, the record's own content is returned.
What the caller supplies and what the server derives
A read passes its context in the contexts argument: device, platform, locale and any custom dimension you have defined. A dimension the caller leaves out is absent, so a rule that tests it does not match.
Sign-in status, segment membership and a user's profile data are never taken from the caller. The server works them out from the signed-in user's token and ignores a request that tries to send them.
What comes back
The winning variant's values arrive merged onto the record's ordinary fields, and _variant names the variant that was served. A response containing a variant-resolved record is marked private, so a shared cache does not store it.
Read the detail
The variants guide covers creating and publishing variants, and the variant catalogue guide covers targeting entries and priority.