Lab - Create a Customer Flow in Postman
Lab - Create a Customer Flow in Postman
Lab - Create a Customer Flow in Postman
In this exercise, you’ll build a workflow in Postman that mimics the standard operations a headless storefront would utilize to allow customer registration, address management, and login.
To get the full benefit from this workflow, you should make sure that you have configured one to three custom Form Fields for customer account signup.
In your BigCommerce control panel, manage Form Fields in Settings > Advanced > Account sign up form. You’ll be building support for Account Signup Fields, not Address Fields. The following field types will be supported in your Postman logic, so make sure to set up one to three custom fields of one or more of these types.
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_tokenBefore beginning the following exercise, make sure to run “REST Create Private Token (server-to-server)” to populate private_storefront_token on the environment with a valid token.
In order to provide appropriately formatted custom field values for the account, you’ll first need to inspect the details of those form fields.
This query inspects the details of the user-defined customer account registration Form Fields. Specifically, the details of the types RadioButtonsFormField, PicklistFormField, DateFormField and TextFormField.
The post-response script you’ll set up next will not only verify that at least one custom Form Field exists, but will also store collection variables with appropriate values for the fields that were found, in a format ready for the customer registration mutation you’ll configure later.
This script adds one more test in the case of multi-choice style fields, verifying that at least one option exists.
From here, the script will store three different collection variables with values that will be expected by customer account registration. Which variables contain values will depend on the types of Form Fields you configured in your control panel.
Send the request again and verify that the variables customer_multiple_choices, customer_dates, and customer_texts are populated on the collection, with appropriate values depending on the types of your fields.
These values will be used both for account registration and for login, which is why you’re storing them in a persistent location.
Don’t send the request just yet, as you’ll want to have post-response scripts in place before registering the new account.
In this request, you’ll use the login mutation to authenticate the newly created customer account, using the same email and password you first used to register the customer.
In addition to verifying the user credentials, this request will also capture the Customer Access Token for use in the X-Bc-Customer-Access-Token header for the subsequent customer requests.
customer_password to a different value, then re-send the request. Verify that tests fail with these incorrect credentials, and observe the response.customer_password collection variable to the correct password.To finish out this request, you’ll capture both the “logged-in” customer’s ID and the unique Customer Access Token in collection variables.
customer_id and customer_access_token variables are set on your collection.Customer addresses have the same support for custom Form Fields that customer accounts do, so you could use the same workflow we have already seen to discover and then populate these fields when adding a new address. For simplicity’s sake, we’ll skip these custom Form Fields for addresses, providing only built-in field values. In order for this request to work correctly, you’ll need to make sure you have no Form Fields configured for addresses that are required.
You’ve captured a unique Customer Access Token identifying the “logged-in” customer in the previous request, and that context will be provided not in the body of the mutation or its variables, but in the X-Bc-Customer-Access-Token header.
The following requests will simulate the workflow required to allow a user to initiate a password reset request, then complete the password reset using the token provided in the resulting email.
If you wish to try out this workflow, this will require the ability to receive the password reset email sent by BigCommerce and retrieve the token provided in the reset link it contains.
You should therefore make sure that email address used previously to create the customer account is one for which you can successfully receive email. If needed, update the customer_email collection variable and re-run the “GQL Register Customer” and “GQL Customer Login” requests to capture the ID of a customer account with a valid email.
Note that you’re entering a purely arbitrary URL path to serve as the “password reset” destination on a hypothetical storefront. Your own application would be in control of what URL route is appropriate for customers to be directed to.
If your previous request succeeded, this should have initiated a reset email to the address associated with the customer account. The token needed for the password reset request can be obtained only from this email.
This email should contain a link to a URL like the following:
https://{store-domain}/my-password-reset?c={customer-ID}&t=**{token}**
Note the URL path /my-password-reset, which was designated by the requestPasswordReset mutation itself. The part of the URL you are now concerned with is the {token} value passed to the t querystring parameter.
password_reset_token with the token value you copied.In this request, you’ll complete a customer password reset using the token value you previously captured.
The intent is to update the customer account password with a new value, so you’ll need to start by providing this new value to Postman.
customer_password variable to a different password string.