Install Idukki on Salesforce B2C Commerce (SFRA) (early access)

Status

Part	What it does
Storefront widget	Async loader on every SFRA page, an automatic or one-line product page widget, and a Page Designer component.
Catalogue	A job that sends masters with variants and standalone products, with prices, availability, images and URLs.
Orders	Each order placed through SFRA checkout, sent with the visitor id, retried by a job.
Status page	Business Manager page to test the key and see the last sync, last order and last error.
Add to cart in the gallery	Built into the widget for SFRA (it uses the storefront’s own Cart-AddProduct) and arriving with early access.

Requirements

Salesforce B2C Commerce with an SFRA storefront (app_storefront_base). PWA Kit and headless storefronts are not covered.
Your Business GUID and at least one widget GUID, from the embed code in the Idukki dashboard.
A store connection key (see Connect).

Install

Upload cartridges/int_idukki and cartridges/bm_idukki to your code version with your usual tool (sfcc-ci, b2c-tools, the Prophet uploader or CI). Keep the folder names.
Storefront cartridge path: put int_idukki left of app_storefront_base and left of any cartridge that replaces CheckoutServices-PlaceOrder, for example app_custom_mysite:int_idukki:app_storefront_base.
Business Manager cartridge path: add bm_idukki:int_idukki.
Zip metadata/site_template (with the folder inside the zip) and import it under Administration, Site Development, Site Import & Export. It adds the Idukki Site Preferences, the Order attributes, the IdukkiStatus custom object and the idukki.http.partner service.

Connect with a store connection key

In the Idukki dashboard open Settings, then the Salesforce Commerce Cloud tab under Integrations, and create a key in the Store connection card. Early-access accounts have the tab switched on for them.

The key starts with idk_pc_ and is shown once, when you create it. Idukki keeps only a hash of it, so a lost key cannot be shown again: revoke it and make a new one. One key belongs to one store and one platform; a Magento key is refused by a PrestaShop store. Revoking a key in the dashboard stops the module at once.

Site Preference (Merchant Tools, Custom Preferences, Idukki)	Value
`idukkiApiBase`	`https://api.idukki.io` (default). Must be https.
`idukkiConnectionKey`	The `idk_pc_` key. Password type, stored encrypted, masked in Business Manager.
`idukkiBguid`	Your Business GUID. Empty turns the storefront integration off.
`idukkiDefaultWidget`	Widget GUID for product pages and for Page Designer components without one.
`idukkiPdpSelector`	Where the product page widget goes. Default `.product-detail .description-and-detail`; empty means no automatic placement.
`idukkiRequireConsent`	On loads the widget only for shoppers who accepted SFRA tracking consent.
`idukkiEnableOrders` / `idukkiEnableCatalogue`	Send placed orders / allow the catalogue job to send products. Both on by default.

Grant Idukki, Connection status to the Business Manager roles that need it, then open Merchant Tools, Idukki, Connection status and press Test connection. It shows the platform and store URL Idukki has for the key, or why the call failed.

Schedule the jobs

Job	Step and schedule
`Idukki-CatalogueSync`	`custom.Idukki.CatalogueSync`, `Mode` = `full`, daily. Run it once after setup.
Catalogue delta (optional)	Same step with `Mode` = `delta`, for example hourly. Price book and inventory changes do not change `lastModified`, so keep the nightly full run.
`Idukki-OrderExport`	`custom.Idukki.OrderExport`, every 15 to 60 minutes, retries failed orders. `BackfillDays` sends older orders once; they carry no visitor id.

Place widgets

The loader is added to every page that uses SFRA’s common/layout/page.isml through the app.template.afterFooter hook as soon as idukkiBguid is set.

Product pages, no code. With idukkiDefaultWidget and idukkiPdpSelector set, the widget is placed after the selector. If the selector is not on the page, nothing is shown.
Product pages, exact position. Add <isinclude template="idukki/pdpWidget" /> to your productDetails.isml override; automatic placement then steps aside.
Page Designer. Add the Idukki UGC gallery component, with an optional widget GUID, product filter and heading.
Any other template. Copy the mount markup below with your own data-guid.

What every mount rendershtml

<div data-ugc="idukki" data-bguid="..." data-guid="..." filter-pid="<product id>" data-platform="sfcc"></div>

filter-pid is always the id the catalogue job sends: the master id for variation products.

With idukkiRequireConsent on, the loader is emitted only for shoppers whose SFRA tracking consent is true. The check runs in an uncached remote include, never in the cached page, and shoppers who have not answered get a small listener that loads the widget when they accept in SFRA’s consent dialog. If you use a different consent manager, leave the preference off and load the loader from your consent manager instead. If your storefront sends a Content-Security-Policy, allow https://idukki-cdn.com for scripts.

What data is sent

Call	Data
Ping	Nothing but the key.
Catalogue	Product ids, names, URLs, image URLs, prices, availability, manufacturer SKUs, variation values. Offline products are skipped and never sent as deletions.
Orders	Order number, creation time, currency, gross total, status, customer number (registered shoppers only), order UUID as the cart id, Idukki visitor id, line items (master id, variation id, SKU, quantity, unit price).
Never sent	Shopper names, emails, phone numbers, addresses or payment data.

Communication logging for the service is off by default; if you turn it on, the log callbacks redact the key.

How orders are matched to widget activity

After SFRA places an order, the cartridge stamps the visitor id cookie on the order and makes one call to POST /webhooks/partner/orders, with a 3-second timeout and a circuit breaker, so an Idukki outage costs checkout one short wait and then nothing. The shopper’s response is never changed. A failed send is retried by the order job (six attempts in total). Orders placed outside SFRA checkout (OCAPI or SCAPI, call centre, imports) are not sent inline.

Idukki matches each order to widget activity through the visitor id first, then the customer id and the cart id. An order counts as proven only when the same visitor added a product they bought to the cart from the widget beforehand. Orders that only followed a widget view or click land in the influence tiers, and the rest are store orders. The dashboard keeps proven, influenced and store orders in separate columns and never adds them together.

Troubleshooting

Symptom	Check
Test connection: HTTP 401	Key copied incompletely or revoked. Create a new one.
Test connection: HTTP 404	Wrong `idukkiApiBase`, or the store connection release has not reached your account yet.
Timeout or circuit breaker	Administration, Operations, Services, `idukki.http.partner`: enabled, not in mock mode, outbound access to the API host.
No widget	`idukkiBguid` set, the page uses `common/layout/page.isml`, and with consent required, consent given.
Orders not arriving	The status page’s retry count and each order’s Idukki attributes. Check `int_idukki` sits left of any cartridge replacing `CheckoutServices-PlaceOrder`.
Status page missing	`bm_idukki:int_idukki` on the Business Manager path and the module granted to your role.

Logs: custom category idukki under Administration, Site Development, Development Setup, Log Files.

Uninstall

Disable or delete the Idukki-* jobs.
Remove int_idukki from the site cartridge path and bm_idukki from the Business Manager path. The loader, widgets, order feed and status page stop at once.
Clear idukkiConnectionKey and revoke the key in the Idukki dashboard.
Optionally delete the metadata (Site Preference and Order attributes, the IdukkiStatus type, the services) and any idukki/pdpWidget includes or Page Designer components you added.

Magento 2 PrestaShop WooCommerce BigCommerce