REST API enhancements

WebSphere Commerce provides several privacy-oriented REST API enhancements. Some are designed to provide the ability for shoppers to opt-in or opt-out of providing consent for any targeted personalization or marketing activities or promotions. Others are for internal use by Data Protection Officers.


Storefront REST API enhancements

The following six scenarios show user interactions that call updated REST APIs. These are storefront-oriented REST enhancements.


A guest user adds a product to the shopping cart

When a user first accesses an e-commerce site and is browsing product pages, the user is running as a generic user. The generic user has a common user ID (-1002) used across the entire system. The use of a common user ID on the site minimizes system resource usage. When the user performs an operation that requires a unique identity, for example, adding a product to the shopping cart, the user is converted from a generic user to a unique guest user. For all REST services that require creating a guest user, the REST service layer supports processing privacyNoticeVersion and marketingTrackingConsent data, which is required as part of the REST services call along with the following cookies:

The guestidentity REST service can also be called to create a guest user. This service is enhanced to accept two parameters in the POST: privacyNoticeVersion and marketingTrackingConsent.

See POST /store/{storeId}/guestidentity.


A generic user logs in as a registered user

When a user logs in using their user name and password, it calls loginidentity to log in. This REST service is enhanced to return two more attribute information parameters: privacyNoticeVersion and marketingTrackingConsent. These two attributes values can be used to check whether the privacy policy window pops up or not. For example, if the privacy notice version is updated to a newer version after comparing it with the WC_PrivacyNoticeVersion_{storeId} cookie, the just-in-time privacy notice window is displayed. This window shows the updated version to the user.

See POST /store/{storeId}/loginidentity.


A generic user registers

When a generic user registers, it calls the REST service to create a new user. This REST service is enhanced to accept two new parameters in the post body: privacyNoticeVersion and marketingTrackingConsent.

See POST/store/{storeId}/person.


A registered user views their account information

When a registered user views their account information, the REST service to get the account data is enhanced to return extra attributes: privacyNoticeVersion, privacyNoticeVersionTimestamp, marketingTrackingConsent and marketingTrackingConsentTimestamp.

See GET /store/{storeId}/person.


A registered user updates their account information

A registered user can update their marketing consent from the Account page, where the person REST service can be called. This REST service is enhanced to accept two parameters in the body: privacyNoticeVersion and marketingTrackingConsent. Accordingly, if the user opts out from marketing consent, the user behavior data is removed .

See PUT /store/{storeId}/person/@self.


A user launches the Privacy page from the footer to update their marketing consent

A user can view the Privacy page and change their marketing consent data. The /store/{storeId}/event/update_marketing_tracking_consent service is called to update the marketing consent data. If the user opts out from marketing consent, the user behavior data for this user is removed accordingly.

See POST /store/{storeId}/event/update_marketing_tracking_consent.

REST API enhancements for Data Protection Officers

The following five scenarios show how a Data Protection Officer can retrieve and remove user data according to a customer's request or other criteria. The default user role for these services is spiuser. We can change the user role to suit your needs.

A user requests that their personal information be removed from the store

Your developers can provide a Data Protection Officer with tools to delete a customer's personal information from the WebSphere Commerce database. The /store/{storeId}/person/{userId} service is called to erase all customer data.

When personal data is deleted, the person's name and address, all the orders, addresseses, user accounts, member roles, wishlists, and payment information that belongs to that person will be deleted.

See DELETE /store/{storeId}/person/{userId}.

A user requests that their order history be deleted

The user's order history can be deleted using a single REST service call. The /store/{storeId}/order/@history?userId={userId} service is called to erase the customer's order history.

See DELETE /store/{storeId}/order/@history?userId={userId}.

A Data Protection Officer or customer asks for user behavior data collected for marketing activities

The Data Protection Officer wants access to a customer's user behavior data because that data is obsolete, or the customer has opted out of a particular marketing activity. The /store/{storeId}/user_behavior?userId={userId} service is called to retrieve user behavior data.

See GET /store/{storeId}/user_behavior?userId={userId}.

A customer's user behavior is to be deleted, upon request or according to other criteria

A customer's user behavior can become obsolete, or otherwise be flagged for deletion upon request, according to policy etc. The /store/{storeId}/user_behavior/{userId} service is called to delete user behavior.

See DELETE /store/{storeId}/user_behavior/{userId}.

A customer asks for their wish list

A customer or Data Protection Officer can ask for the customer's wish list. The /store/{storeId}/wishlist?userId={userId} service retrieves the wish list.

See GET /store/{storeId}/wishlist?userId={userId}.


Related concepts
General Data Protection Regulation (GDPR) and WebSphere Commerce