Lab - Create a Catalog Flow in Postman
Lab - Create a Catalog Flow in Postman
Lab - Create a Catalog Flow in Postman
In this lab, you’ll build on the Postman entities created in the previous exercise to create a progressive catalog workflow, querying for lists of categories and products and then using the results to query for more specific information.
You may choose to use an API client with similar features and adapt the following instructions, but the instructions themselves assume the use of Postman.
Certain catalog data must be present in your BigCommerce store in order for the exercise queries to succeed. We’ll detail the requirements below.
Your BigCommerce store must contain a top-level category (which can be different than the category with child categories) that:
Your BigCommerce store must contain at least one product that:
As a reminder, your work in previous labs should have resulted in the following Postman configuration, which will be important for the following exercise steps:
v3_token, store_hash, storefront_channel_id and private_storefront_tokenprivate_storefront_tokenprivate_storefront_token when runWe are querying for categories and their children, starting at the root of the store and querying three levels deep. Since the fields we are querying for each hierarchy level are the same, we are using a GraphQL fragment to specify them.
The following tests will verify that the Category Tree request returns at least one top-level category with products.
We’re now going to store the ID of one of the top-level categories in a collection variable, which will be used in our next request. With this flow, you can run the requests in sequence rather than needing to manually find and enter a category ID for the individual category request.
Note that we’re storing this value in a collection variable, rather than in an environment variable as we’ve done before. We’ve used environment variables for values that are likely to be relevant in numerous contexts when connecting to a particular environment, while values specific to the workflow we’re implementing are stored on the collection.
category_id is populated in the Variables tab of the collection.Now we’ll use the category ID we found in the previous request to query information about a specific category.
We’ve used a GraphQL variable in the query to specify a category ID, and now we’ve used our Postman environment variable to populate that value in the GraphQL variables list.
These tests will verify we successfully received the category in the response.
This time around, we don’t have any important response values to store.
We’ll now create not only a query for the store’s products, but one which can be run multiple times in sequence to page through results.
We’re querying for basic product information but also information about the products’ variants. We’ll ultimately be using this information to find a product with at least one variant.
Notice that we’re passing last_product_cursor to the after argument in the query, which controls where in the cursor list we want the query results to start. But we currently have no such Postman variable in our collection or environment.
When the query is run with no such variable, we will get the first 5 results.
Let’s add tests to make sure the query returns products, and at least one of those products is physical, is available, and has at least one variant.
If you don’t have a product with variants in the first 5 results of your store’s products, you’ll see that the final test fails, even though this doesn’t really constitute an unexpected response. That’s okay for now, as this test will be our indicator for when we’ve finally found such a product once we’re able to run through multiple pages of results.
In order to page through results by running this request multiple times, we must capture the ending cursor of the current page.
last_product_cursor should now be populated in your collection variables.last_product_cursor variable in order to “start over” the next time you send the request.Our last task with the paginated products request is to find and store the ID of the first product with variants that is found.
Why variant ID?
We are storing the first variant ID as well as the product ID in a collection variable, even though we don’t need this for our next request. This will be useful for a later lab.
We’ve now created a workflow by which you can clear out the value of the last_product_cursor variable on your collection, then send the “Get Paginated Products” request multiple times if necessary until all tests pass. By that point, a product ID and variant ID will have been captured.
product_id and variant_id variables are populated in the collection.This query will fetch some of the finer details of the product, including the price and default image URL. Of particular note is the information fetched about product options: Since we know we’ll be querying for a product with variants, these details will demonstrate how variant information shows up in the available product options.
Before sending this request, make sure you have used the “Get Paginated Products” request to capture a product ID.