Overview

By integrating a grocery store into Whisk, the grocery store will be available within Whisk’s platform. This means the store can choose whether the store appears:

  1. Within every consenting partner on Whisk’s platform (this includes recipe publishers, IoT apps like Samsung and users of Whisk’s APIs)
  2. Exclusively for one or more partners within Whisk’s network

Various use cases for retailer scan be found here: https://whisk.com/retailers/

Upon integration, a retailer becomes available to users based on these rules: 

  • Across all Whisk platforms/sites (option A) or on only specific sites/partners (option B)
  • Users in the relevant locations (geo-location)

Technical integration

There are two parts to an integration:

  • Product mapping: Products are mapped to Whisk’s internal ontology which allows Whisk to display the correct store products against shopping list items. 
  • Authentication: A link between Whisk and the store to allow users to fill their store baskets with a number of product IDs. 

Typical user flow:

Integration process

Technical integration methods

There are two components to the integration: 1. Product Matching and 2. Store Authentication. 

Product Mapping

Whisk uses two methods to map store products to ingredients.

1. Using Whisks’ Food Genome (recommended)

Whisk syncs a store’s inventory into the Whisk platform. This can be achieved through an API or by pulling in inventory from a retailer's website using web crawlers. Inventory at the retailer is typically synced every 24 hours. Whisk then uses the following to make the links between products and shopping list items: 

  • Natural Language Processing: Whisk matches all products to it’s proprietary ontology, the Food Genome, automatically using Deep-learning based Natural Language Processing
  • Product mapping: Most shopping list line-items have multiple possible products from retailers, so Whisk selects defaults based on algorithms which select “best matches”. These are based on the most appropriate product for an item in a user’s shopping list based on: Item required (what’s closest), quantity required, attributes (e.g. organic, fresh, frozen), price, personal preferences and other attributes. Whisk’s interface allows users to switch the default choices. 

2. Using a store’s own matching (alternative)

If a store has their own product matching capability, this can be used instead. This typically allows Whisk to pass in a simplified ingredient (e.g. “<5>, <Carrot>” instead of “5 carrots cut into small pieces and washed”). It may also allow Whisk to authenticate a user in order to use their store loyalty scheme to find personalised matches based on a user’s in-store purchases. 

Store authentication

Whisk then needs a method through which to send lists of items to a users’ basket at the retailer. This can be achieved using:

  1. OAuth/SSO APIs (best-practice, recommended)
  2. Through methods where Whisk passes a user’s credentials (username / password) to the store through other means (alternative) 

Store Authentication methods 

Whisk uses two methods to authenticate supermarket. 

1. OAuth / SSO (Single Sign On) integration

This integration method is preferred because it’s (a) more stable, (b) is faster to integrate and (c) requires no login from user once the store transfer is complete (the user can land on a pre-logged-in store page).

2. Username & Password integration

This integration method requires a user to login at the store once the items have been transferred. The user is not automatically logged in on their device. 

If a partner wishes to mitigate security responsibilities involved with step #1, Whisk can provide it’s authentication interface directly in the CA, both the turnkey (via iFrame) and API (via OAuth) integration.

Did this answer your question?