Personalized Catalogs
On this page
B2B product catalogs tend to be complex, with many product variations and specific terms and conditions for each buyer account. Often, the B2B purchasing process is also more complex, involving different users with different permissions. With Algolia, you can use secured API keys to ensure each signed-in user can search or browse only the part of the product catalog they’re entitled to access.
Entitlement policies
Sellers often create a public product catalog for all users that aren’t signed in. For each buyer, sellers can create a custom product catalog visible only for signed-in users associated with the buyer account. In B2B the main buyer entity is a company account, that can have many user accounts with different access permissions, depending on their roles and responsibilities in the purchasing process. An administrator role would have full permissions. A company account’s administrator would then define further roles with permissions according to the unique requirements of the company. For example, a buyer role could have access to all Sales and Quotes resources, were a view-only role would be able to browse the custom product catalog and view orders, quotes, and other information, but not place orders.
Your search and browse strategy needs to respect:
-
Per-account entitlement policies. Each signed-in user can only search and browse the custom product catalog according to their company account. Thy should only see the products and conditions defined between the buyer and seller, such as variants, bundles, minimum order quantity, pricing, and more.
-
User-level entitlement policies. Each signed-in user can only search, browse, and interact with the product catalog according to their roles and permissions, as defined by the buyer account’s administrator.
What are secured API keys?
When searching in an Algolia index, you need to send an API key with your search request to authenticate with Algolia. With your Search-only API key, users can search the full product catalog. From this key, you can derive secured API keys with more restricted scopes.
For example, you can use secured API keys to:
- Restrict the search to a specific index
- Apply predefined filters to every search
- Apply predefined search parameters to every search
When you apply search parameters and filters when creating secured API keys, users can’t override or remove them at search time.
Accessing personalized product catalogs with secured API keys
At a high level, using secured API keys has three steps:
- A user starts searching. Your front end needs a secured API key.
- Your back end creates a secured API key and sends it to the front end. The secured API key has a pre-applied filter that can’t be changed at search time.
- Your front end uses the secured API key to query Algolia.
Implementing secured API keys
To implement secured API keys, follow these steps:
-
Prepare your index. Add an attribute to each record that signals who has access to this record.
Copy1 2 3 4 5
{ "objectId": "product-123", "visible_by": ["company-1", "company-3"], ... }
In this example, this record should only show for users from company 1 or company 3, but not for other users.
-
Create a secured API key on your back end. To prevent exposing the search API key, you need to create the secured API key on your back end. Otherwise, users can override the restrictions built into the secured API key and access the whole product catalog.
To create a secured API key with the JavaScript API client:
Copy1 2 3
const publicKey = client.generateSecuredApiKey('SEARCH_API_KEY', { filters: `visible_by: ${groupID}`, })
This binds the filter to the API key which can’t be changed at search time. To apply this filter, your search back end needs to get the group membership of the signed-in user from your ecommerce platform.
-
Communicate the API key to the front end. Your front end can request the secured API key from the back end:
Copy1 2 3 4 5 6
function getPublicKey() { const apiKey = fetch('BACKEND-URL/api-key') .then((response) => response.json()) .then((data) => data.apiKey) return apiKey }
On your back end, you need to create a corresponding API resource, for example, using
express
:Copy1 2 3 4 5 6 7 8 9 10 11
... const express = require("express"); const app = express(); app.get('/api-key', (_, res) => { const publicKey = client.generateSecuredApiKey("SEARCH_API_KEY", { filters: `visible_by: ${groupID}` }); res.send({ apiKey: publicKey }); })
If your front and back ends are on the same server, you can also inline the API key.
When searching, your front end uses the secured API key:
1
2
3
4
5
6
...
getPublicKey().then(publicKey => {
const searchClient = algoliasearch("APP_ID", publicKey);
const search = instantsearch(indexName: "INDEX_NAME", searchClient);
...
});
The results only show records where the group ID of the current user matches the visible_by
attribute.
Using Algolia with Adobe Commerce
The Algolia integration for Magento 2 supports the Catalog permissions and B2B shared catalog features of Adobe Commerce.
If you enable this feature in Adobe Commerce, the Algolia extension adds a catalog_permissions
attribute to your records.
This attribute lists customer groups and whether a product or category is visible for that group.
When searching, the results only contain products that are visible for the current customer group.