In this lesson, you will run queries against the project's Content API in the API Playground. The exercises follow the same order the schema was built: basic model queries first, then references, then components, then remote data. Each exercise proves that a specific set of schema decisions works as configured.

Navigate to the API Playground in your project sidebar to get started.

#How queries are generated

Hygraph automatically generates queries for each model when it is created. Two queries are generated per model, named after the model's API ID and Plural API ID. The API ID fetches a single entry. The Plural API ID fetches multiple entries.

The Product category model is a good example. In the API Playground tree, productCategory fetches one category entry and productCategories fetches all of them. Expanding productCategories in the tree shows all the fields added to the model: categoryName, slug, description, and products.

API Playground with displayed tree

Queries can be built by selecting fields in the tree or typed manually. All exercises below can be copied and pasted directly into the API Playground.

#GraphQL 1

This query fetches all product categories. The Plural API ID productCategories returns multiple entries.

The description field uses text as the output format because it was added as a Rich Text field in lesson 1.2. Rich Text fields require an explicit output format — text, html, markdown, or raw. Omitting the format returns an error.

#GraphQL 2

This query fetches all products in the New arrival category using a where filter on the category slug.

The products field is queryable here because of the two-way many-to-many reference configured in lesson 2.1. The two-way direction is what makes it possible to navigate from a category to its products.

#GraphQL 3

Try this yourself: Find the productName and productSlug of all products in the urban category.

#References 1

This query fetches the related products connected to the plaid shirt entry. The relatedProducts field is a basic component field added to the Product model in lesson 4.2. The component contains a title field and a products reference field.

The title field returns Related Products for every entry because it was configured as a read-only field with a fixed initial value in lesson 4.1.

#References 2

This query fetches all products in the sportswear category along with their product descriptions in HTML format.

This response requires the additional practice entries from lesson 6.1. If you only created the core five products, Sportswear may return fewer results.

Items in the sportswear category

#References 3

Try this yourself: Query the sellerInformation reference on the homepage landing page entry. Find out the businessName and businessDescription.

#Components 1

This query fetches the productVariant component for the headband entry. Because productType is a modular component field, the query uses an inline fragment (... on Accessory) to specify which component type to query and which fields to return from it.

Inline fragments are required for modular component fields because the API needs to know which component type's fields to return. You can include multiple inline fragments in the same query to handle all possible component types simultaneously. For example, ... on Clothing { size color } alongside ... on Accessory { color }.

#Components 2

This query fetches the relatedProducts component for the blue running shoes entry, returning product descriptions in HTML format.

#Components 3

This query filters all products by a value inside the productVariant modular component, specifically all Accessory type products where the color is White.

Filtering on a modular component field uses the component type name (Accessory) as a nested key in the where clause. The same pattern applies to Clothing, Shoes, and Decor.

#Components 4

Try this yourself: Query the stripes modular component inside the homepage landing page entry. Find the productName and productSlug of all products added to the Product Grid section.

#Remote Fields 1

This query fetches all products and their reviews from the remote field configured in lesson 5.2. The reviews field lives on the Product model and returns data from the HyDemoAPI remote source scoped to each product's slug.

Some products return an empty data array. This is expected because the HyDemoAPI only contains reviews for products whose slugs match entries in its dataset. Products with no matching reviews return an empty array, not an error.

#Remote Fields 2

This query fetches reviews scoped to a single product, the plaid shirt, using a where filter on productSlug. The remote field path uses {{doc.productSlug}} as the argument, so only reviews for that specific slug are returned.

#Remote Fields 3

Try this yourself: Query the reviews remote field inside the Product model for the blue-running-shoes entry. Return the rating and comment for each review.

#Top-level Remote Fields 1

This query fetches landing page data and review data in a single API call. The landingPage and reviews fields are at the same level in the query because reviews is a top-level remote field on the Query model. It is not nested inside any content model.

A single API call returned both Hygraph content and external review data with no middleware. This is Content Federation working as configured in lessons 5.1 through 5.3.

#Top-level Remote Fields 2

Try this yourself: Query the reviews top-level remote field for productSlug: "plaid-shirt". Return only the product and rating fields.

#What's next

Lesson 7.2 - Write mutations

Or, go to the Tutorial overview for the full lesson list.