HomeDev guideRecipesAPI ReferenceGraphQL
Dev guideUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Optimizely Graph schema

Describes how to access the GraphQL schema for the Optimizely querying service, when retrieving content in Optimizely solutions.

Optimizely Graph uses a GraphQL schema to describe the shape of the data available to client applications that call the service. The schema defines a hierarchy of types and fields that are populated from the back-end data store. The schema also specifies which queries and mutations are available for clients to execute against the data graph.

Optimizely Graph generates a unique schema for every site that syncs its data to the service. The shape of the data depends on how the content types are defined in that site's configuration. Exploring your sites uniquely generated schema is an essential part of build query-driven applications with Optimizely Graph.

Access the schema

Access the API Gateway with your public key to find the generated GraphQL schema. See Getting started with the GraphQL API. You can also use the GraphQL UI to access the GraphQL schema.


Methods and parameters

GraphQL schemas contain one method per content type, and each method contains several Parameters. Each method has a return type that matches the properties for the content type. This lets you select which content type properties to return in the result.

Field names, reserved fields, and characters

GraphQL schemas contain regular field names of content, reserved field names, input arguments, enumerated values, and reserved characters. The (naming) convention for these parts of a schema is as follows:

  • Field names (regular) follows the conventions of the site's content delivery model. For example, if the model is serialized as Pascal case, the fields also appear as Pascal case in the GraphQL schema. These fields appear in the Input and Output types.
  • The schema type or name of the schema is in Pascal case (PascalCase).
  • Reserved field names are field names starting with an underscore prefix that allow special functionality:
    • _fulltext – a concatenation of the values of searchable fields.
    • _children – a special field that embeds a method for a content type within a parent content type.
    • _ranking – orders results by a relevance score, internal document ID or other special metrics.
    • _modifie` – a date field that indicates when the content was ingested.
    • _or, _and and _not – used for expressing Boolean logic in queries.
  • Root-level fields are fields in camel case (camelCase):
    • items – the root level for projecting the actual results.
    • total – shows the hit count or number of matching results given by the query.
    • facets – projects the aggregated values of a field, including matching hit count. These values can then be used for filtering.
    • cursor – shows the value that can be used to do pagination with a cursor.
  • Input argument are names of arguments in a method that follow snake case (snake_case) convention.
  • Enumerated values are fixed values in uppercase (UPPERCASE) and snake case belonging to input arguments or reserved fields:
    • the reserved field _ranking has the values RELEVANCE and DOC.
    • locale argument has different language codes like EN, SV, FR, and so on..
  • Reserved characters are part of the GraphQL syntax and need to be escaped with a single backslash for querying. These characters are double quote (\") and backslash (\\).

The following illustration summarizes these conventions hierarchically: