Which storefronts does this cover?

Both the composable storefront (formerly Spartacus) and the older Accelerator storefronts. The integration is a plain script tag, so the constraint is where your storefront lets you add markup, not the platform version.

Composable storefront or Accelerator, does the method differ?

Only in which file you edit and what you have to rebuild. The composable storefront takes the tag in src/index.html and needs an Angular rebuild; Accelerator takes it in a tag file and needs an extension rebuild and a platform restart.

Does it work with server-side rendering?

Yes. The tag is part of the document shell, so it is present in the SSR output, and the widget executes in the browser after hydration.

Do I need a CSP change?

Only if your storefront sends a Content Security Policy, which is common behind a CDN. Where one is set, add the widget host to script-src.

Other platforms and frameworks

Inclusify installs on any platform that lets you add one script tag before the closing </body> tag. That tag is <script src="https://app.inclusifyapp.com/w/YOUR-DOMAIN.com.js" async></script> and it is the whole integration: there is no plugin, extension, package or app to install, and nothing to configure on the platform side. The bundle is built per registered domain and checks window.location.hostname against the domains registered to your Inclusify website before it renders anything, so every hostname you want the widget on has to be registered, staging and preview hostnames included. localhost and 127.0.0.1 are the only exemptions.

Register the domain first

Add your domain in the Inclusify panel before you paste the script tag. Bundles are built per registered domain, and an unregistered one fails silently: the script URL still returns HTTP 200, but what it serves is a single console.log saying the domain is not registered. There is no error to find and no widget appears.

SAP Commerce Cloud

Inclusify installs on SAP Commerce Cloud as one script tag in your storefront’s document shell: on the composable storefront that is src/index.html, the file the Angular build inlines, and on Accelerator it is the tag file that wraps every responsive page. There is no Inclusify extension or addon to install and no SAP-side configuration. What it needs is a developer with commit access and a build, so treat it as a release rather than a settings change, and rebuild before you conclude it did not work.

Spartacus / Composable Storefront (Angular)

For Spartacus storefronts, add the script to your index.html:

src/index.html

<script src="https://app.inclusifyapp.com/w/YOUR-DOMAIN.com.js" async></script>

Add before the closing </body> tag, then rebuild and redeploy - Angular inlines this file at build time, so an un-rebuilt bundle keeps the old markup.

Accelerator (JSP)

For Accelerator storefronts, add the script near the end of the master tag file: the tag that wraps every responsive page, rather than a footer template of its own. Confirm the path in your own storefront extension, because the extension name is generated when the storefront is created and the tree differs between Accelerator versions:

yacceleratorstorefront/web/webroot/WEB-INF/tags/responsive/template/master.tag

<script src="https://app.inclusifyapp.com/w/YOUR-DOMAIN.com.js" async></script>

Rebuild the storefront extension and restart the platform afterwards - JSP and tag files are cached by the application server.

SAP storefront notes

• There is no version constraint to check. The integration is a script tag in markup you already control, so the question is only where your storefront lets you add markup
• Works with the composable storefront, formerly Spartacus, and with Accelerator. Only the file you edit and what you rebuild differ
• Check the live storefront, not SmartEdit, which renders the storefront inside an authoring iframe. The widget can be absent from that preview while working in production
• Register every environment’s hostname in Inclusify, not only production. The bundle refuses to run on a hostname it does not recognise, and staging hostnames are the ones you test on

Verify the installation

Rebuild and redeploy after editing index.html. Angular inlines that file at build time, so an un-rebuilt bundle keeps the old markup.
For SSR deployments, confirm the server-rendered HTML contains the tag by using View Source rather than the DevTools element inspector.
Register each environment's hostname in Inclusify, not only production. The bundle checks window.location.hostname against the domains registered to your Inclusify website before it renders anything, and logs "Inclusify: This widget is not licensed for" and that hostname when it does not match. localhost and 127.0.0.1 are the only exemptions.
Load a product detail page and a cart page, not just the home page.
Check the live storefront rather than SmartEdit, which renders the storefront inside an authoring iframe.

Widget bundles are served from a CDN and cached for a few hours. If you changed widget settings in the panel and the site still shows the old configuration, wait for the cache to expire or load the script URL directly with a cache-busting query string (`?v=2`) to confirm the new version is being served.

Troubleshooting SAP Commerce Cloud installs

The tag is in index.html but missing from the deployed site.: The Angular build was not rerun. Run the production build and redeploy; the file is inlined at build time and is not read at runtime.
The widget does not load under server-side rendering.: SSR serves pre-rendered HTML from the Node server. Restart the SSR process after deploying so it picks up the new bundle.
The widget is missing inside SmartEdit.: SmartEdit renders the storefront in an authoring iframe. Check the live storefront instead before treating it as a failed install.
A non-production environment logs that the widget is not licensed.: That hostname is not registered in Inclusify. Add each environment's hostname in the panel, or test on the registered one.
Nothing changes on an Accelerator storefront.: JSP and tag files are cached by the application server. Rebuild the storefront extension and restart the platform, then clear the browser cache.

SAP Commerce Cloud questions

Which storefronts does this cover?: Both the composable storefront (formerly Spartacus) and the older Accelerator storefronts. The integration is a plain script tag, so the constraint is where your storefront lets you add markup, not the platform version.
Composable storefront or Accelerator, does the method differ?: Only in which file you edit and what you have to rebuild. The composable storefront takes the tag in src/index.html and needs an Angular rebuild; Accelerator takes it in a tag file and needs an extension rebuild and a platform restart.
Does it work with server-side rendering?: Yes. The tag is part of the document shell, so it is present in the SSR output, and the widget executes in the browser after hydration.
Do I need a CSP change?: Only if your storefront sends a Content Security Policy, which is common behind a CDN. Where one is set, add the widget host to script-src.

SAP Commerce Cloud documentation

Every SAP Commerce Cloud-specific requirement, menu path and limit on this page comes from these pages. Menus move, so check them against your own admin if something does not match.

Script installation generates the embed code for your domain.
Customization covers the position, colour and size of the widget button.

Any other CMS or framework

If your platform is not one of the ones documented above or in the sidebar, the install is still the same one line. Paste it before the closing </body> tag of every page:

Your site's layout template

<script src="https://app.inclusifyapp.com/w/YOUR-DOMAIN.com.js" async></script>

Where the tag goes

It has to be on every page, so put it in whatever your platform renders on every page rather than in one page’s content. In practice that is one of three places: the shared layout or footer template of your theme, a settings field for custom code, which platforms name variously custom code, code injection or header and footer scripts, or a tag manager container that is already loading on every page. Any of the three works, and the tag is inert markup until the browser runs it, so it is safe under server-side rendering and cannot cause a hydration mismatch.

Use Script installation to generate the tag with your own domain already in it.

Confirm it is live

Load a public page of the site in a browser and look for the floating accessibility button. If it is not there, open DevTools: the Network tab should show a request to app.inclusifyapp.com/w/ returning 200, and the console tells you which of the two remaining problems you have. A message that the widget is not licensed for this hostname means the hostname is not registered on your website. No request at all means the tag is not in the page that was served, which on a cached or templated site usually means the template you edited is not the one this page renders.

A platform that strips third-party script tags out of content fields is the one case where the tag cannot go in by hand. Tell us which platform it is and we will work out where it does allow one.