Getting enriched product data onto Optimizely Configured Commerce product pages

Once a distributor's product data is enriched — specs, certifications, use-cases, cross-references — the remaining work is mechanical: get that value into the right Configured Commerce data structure, and make sure the storefront template is wired to render it. This guide covers that path on the current Spire storefront (Configured Commerce's Classic/AngularJS CMS reached end of life on January 1, 2025, so Spire's React/Redux front end is the one to build against today), with a concrete example and a way to validate against a live product page.

Where enriched data can live on a Configured Commerce product

Configured Commerce gives you three distinct places to put a new piece of product data, and which one you pick determines how it renders:

• Attribute Types and Values — a structured, filterable model (e.g., Color: Red/Blue/Green). Attribute Types are assigned to a category, then specific Attribute Values are assigned to each product. This is the right home for enriched data buyers should be able to filter or facet by.
• Specifications — free-form content tabs on the product detail page, built for longer spec-sheet-style content (dimensions, compliance notes, technical detail) rather than faceting.
• Custom Properties — an Application Dictionary extension for a field that doesn't fit the attribute or specification model at all (a raw value you want on the product record and available to the API, without a UI widget out of the box).

Most PIM-sourced enrichment — a rating, a certification, a use-case tag — maps cleanly to Attribute Types/Values or Specifications. Reach for Custom Properties only when the standard model can't represent the field.

Getting the value onto the product record

Attribute-model data: In Admin Console, under Catalog, Products, Attribute Types, create the Attribute Type (e.g., "IP Rating") and its Values (e.g., "IP65," "IP67"), assign the Attribute Type to the relevant category, then assign the value to each product. For bulk loads, the product import template accepts one column per attribute type, named Attribute.[AttributeTypeName] (for example Attribute.IPRating), with the value in each product's row — no hand-clicking hundreds of SKUs.

Specification content: Create one at a time in Admin Console — open the product, go to the Specification tab, click Add Specification, then Create Revision to add the content and Save — or in bulk via import using paired columns per tab: Specification1.Name and Specification1.CurrentDefaultContent for the first tab, Specification2.Name/Specification2.CurrentDefaultContent for the second, and so on. Either way, a Content Approver or Content Admin still has to click Publish — draft content sitting unpublished is a common reason enriched content "didn't show up."

Custom Properties: In Admin Console, go to Administration, System, Application Dictionary; find the entity (e.g., Product), open the Properties tab, and add the property (name, label, property type, control type). This only makes the field visible in Admin Console — by default a new Custom Property isn't returned to, or editable from, the storefront. To expose it, open the Permissions tab on that Custom Property and grant the ISC_StoreFrontApi role; skip this and the field exists in the database but is invisible to the front end and the Storefront API.

How it binds to the Spire template

On a standard Product Details page, Configured Commerce ships prebuilt widgets — Attributes, Specification, Price, Availability, Primary Image, and others — that read from the catalog with no development required. Two are relevant here:

• The Attributes widget renders assigned Attribute Type/Value pairs. A "Display Attributes in Tabs" setting controls whether they show as a list under pricing or as their own tab, with an Attributes Tab Sort Order (Display First / Display Last) controlling where that tab lands relative to Specification tabs.
• The Specification widget renders published specification tabs, with "Show Documents" and "Show Attributes" toggles for whatever else should surface alongside spec content.

For the standard model, that's the whole binding: assign the value, publish it, and the existing widget picks it up — no template edit needed.

Custom Properties don't have a stock widget, so they need a small Spire override. Spire widgets are TSX files under modules/content-library/src/Widgets/[Category]/, each exporting a WidgetModule (a connected component plus a CMS field definition) as its default export. To surface a custom property, create a matching file under your blueprint's src/Overrides/Widgets/[Category]/ directory — the category path must mirror the source widget's folder — and build the override there rather than editing the shipped file. A restart is required the first time you add a new override file; after that, Spire's bundler hot-reloads it.

// Overrides/Widgets/ProductDetail/CustomAttributes.tsx
import * as React from "react";
import { connect } from "react-redux";
import WidgetModule from "@insite/client-framework/Types/WidgetModule";
import ApplicationState from "@insite/client-framework/Store/ApplicationState";
import Typography from "@insite/mobius/Typography";

interface StateProps {
  fireRating?: string;
}

const CustomAttributes = ({ fireRating }: StateProps) => {
  if (!fireRating) return null;
  return (
    <div className="custom-attributes" data-attribute="fire-rating">
      <Typography>Fire Rating: {fireRating}</Typography>
    </div>
  );
};

// The selector that exposes "the current product" lives in the Products
// slice of client-framework/Store and follows the same pattern Configured
// Commerce documents for pages (see getCurrentPage in PageSelectors.ts) —
// confirm its exact name and import path against your SDK version.
const mapStateToProps = (state: ApplicationState): StateProps => {
  const product = getCurrentProduct(state);
  const raw = product?.properties?.["FireRating"];
  return { fireRating: raw ? JSON.parse(raw) : undefined };
};

const widgetModule: WidgetModule = {
  component: connect(mapStateToProps)(CustomAttributes),
  definition: { group: "Product Details", fieldDefinitions: [] },
};

export default widgetModule;

Custom Property values are stored as string key/value pairs in a Properties dictionary, with complex values serialized as JSON within it — so reading one back generally means parsing product.properties["YourFieldName"] rather than reading a plain typed field, whether from a Spire selector or the single-product REST response directly (see the endpoint below).

A concrete walkthrough: a "Fire Rating" spec from the PIM

1. PIM enrichment produces FireRating: "Class A" for a SKU.
2. Push it as an Attribute Value (if buyers should filter by it) via bulk import, or as a Custom Property (if it's just informational) with the ISC_StoreFrontApi permission granted.
3. If it's an Attribute, no template work is needed — the Attributes widget renders it once the value is assigned and the page cache clears.
4. If it's a Custom Property, deploy the widget override above (or add the field to an existing overridden widget) so it renders in the DOM.
5. Confirm the field is returned by a GET request to the single-product endpoint before troubleshooting the widget — if it's missing from the API response, the permission grant (or the import) is the problem, not the front end.

How to validate

• View-source vs. rendered DOM matter differently here than on most sites. Spire renders server-side by default only for requests it identifies as web-crawler user agents; regular browser sessions get a client-rendered shell that hydrates via React. So curl or "View Page Source" on a plain request may show a near-empty shell even when the attribute is correctly wired — that's expected, not a bug. To see what a crawler sees, use a crawler user agent, e.g. curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yoursite.com/product-page, and check the response body for the attribute text. Since release 5.2.2411, Configured Commerce has offered an "Enable Server-Side Rendering for All User Agents" setting; with that on, plain curl output should match too.
• Compare that raw HTML against the browser's Inspect panel (Elements tab, rendered DOM) for the same URL — both should contain the attribute value; if only the rendered DOM has it, SSR isn't picking up the field for crawlers.
• Hit the product record endpoint directly (GET to the versioned api/v1/products path for a single product ID) to confirm the value is present in the API payload independent of any template issue.
• Run the page through Google's Rich Results Test to confirm crawler-visible HTML includes the value if it supports structured data or on-page copy AI agents and search crawlers will read.

Verified as of July 2026 against Optimizely's Configured Commerce developer documentation and Support Help Center articles; Configured Commerce is versioned and admin-configurable, so exact menu labels, import column names, and internal selector paths may vary by release — confirm each against your own instance before shipping.

None of this matters if the underlying data isn't there to bind in the first place. Anglera enriches the product record continuously — attributes, specs, certifications, identifiers — directly in the PIM or commerce platform you already run, so the Attribute Types, Specifications, and Custom Properties above always have something accurate to populate. Your PIM stores the data; Anglera keeps it current, so this page-side wiring only has to happen once.

Sources:

• Use custom properties
• Creating a custom property in the application dictionary
• Product Details Elements widgets
• Manage attributes
• Use the import template for products and related products
• Creating specifications
• Building sites with Spire and React Redux
• Replacing an existing widget in Spire
• Creating a custom widget in Spire: Redux-connected widget
• Server-side rendering (SSR) guidelines for Spire
• Enable Server-Side Rendering in Spire
• Get started with Configured Commerce REST APIs