Virtual Try-On on Salesforce Commerce Cloud

You can add virtual try-on to a Salesforce Commerce Cloud (SFCC) store in two ways: call the ZeDaq.ai REST API from your own code, or add the script-tag widget to your product template. ZeDaq.ai does not offer a Commerce Cloud connector or cartridge, so either route is custom work for your developers.

This guide is for enterprise fashion teams deciding how to build it. For the full API options, read our guide to the virtual try-on API for ecommerce developers.

What can ZeDaq.ai do on a custom storefront?

ZeDaq.ai is AI virtual try-on for fashion stores. The shopper uploads one photo and sees the store's real garment on their body. It can also recommend a size from a 30-second body scan, which is one photo plus height.

There are two ways to use it outside Shopify:

• REST API. Send a request to POST /api/v1/tryon with an x-api-key header. See the API reference.
• Script-tag widget. Paste one script tag into the product template. It adds "Try it on" and "Find my size" buttons.

ZeDaq.ai has no Commerce Cloud cartridge. Any claim that it does would be wrong.

Should you choose the widget or the API?

Pick based on how much control your team needs and how your storefront is built.

Question	Widget	API
Who builds it?	A front-end developer adds a script tag	A developer builds the screens and server calls
How much design control?	Standard buttons and window	Full control of your own interface
Where does the key live?	In the page, locked to your domain	On your server, in a header
Best for	A fast pilot	A branded, deeply integrated flow

For a deeper comparison, read widget versus API for adding try-on.

How would the widget work on SFCC?

The widget is one line of code:

<script src="https://www.zedaq.ai/widget/zedaq.js" data-key="…" defer>

You paste it into the product template. Ask your SFCC developers where the product detail template lives and how front-end assets are loaded in your setup, because that depends on how your site was built.

1. In the ZeDaq.ai dashboard, create an API key under Dashboard → API keys.
2. Lock the key to your store's domain. This is required for the widget.
3. Add the script tag to the product template with your key in data-key.
4. Check that "Try it on" and "Find my size" appear on a product page.
5. Test on staging before production.

Setup details are in the widget docs.

How would the API work on SFCC?

With the API, your server sends the request, and your own interface shows the result. The key stays in the x-api-key header on your server, not in the browser.

A typical plan looks like this:

1. Build a try-on screen on the product page that lets the shopper upload one photo.
2. Send the request from your server to POST /api/v1/tryon.
3. Show the returned image in your page.
4. Handle errors and slow responses so the page does not stall.

The API docs list the request details. Read them before you scope the work, and do not assume fields that are not in the reference.

How do size recommendations fit in?

Merchants enter their own size guide in Dashboard → Size charts, with one chart per garment type: tops, outerwear, dresses and bottoms. The scan recommends your labels and sizes up to the largest relevant measurement. If no chart exists for a garment, a generic UK, US, EU or AU chart is the fallback.

For an enterprise catalog, plan who owns the chart data. Our guide to how stores map measurements to a size chart helps you prepare it.

What does it cost?

Plans are listed on the pricing page, checked November 2026:

Plan	Price
Free	$0
Micro	$14/mo
Starter	$49/mo
Growth	$129/mo
Scale	$299/mo

The Free plan includes 3 try-ons, 3 measurements and 5 invoices a month. Every paid plan has a 3-day free trial with no card required. The pricing page also lists an Enterprise option with custom call volume and an SLA, so contact the team if your traffic is high.

How do other platforms compare?

If you also run, or are evaluating, other storefronts, the answer is the same shape: no dedicated connector, so the widget or the API does the work. Our guides to PrestaShop try-on options and OpenCart try-on options walk through the same decision for those platforms.

How do you run a staged rollout?

Enterprise teams usually launch in phases. A safe order looks like this:

1. Pilot on a few products. Choose a handful of garments with clean photos.
2. Review results. Check the rendered images with your merchandising team.
3. Add size charts. Enter your own size guide for each garment type so recommendations match your labels.
4. Expand by category. Add more products only after the first group looks right.
5. Track usage. Watch your plan limits so you do not run out of try-ons mid-month.

Try-on renders are counted when made through the API, widget or Shopify, so plan your volume against the plan you choose.

What questions should you ask your SFCC team before you start?

A short briefing saves weeks of rework. Put these questions to your developers and your merchandising lead:

• Where does the product detail template live, and who can edit it?
• Can we add a third-party script to that template, and is there a review process for new scripts?
• Do we want shoppers to see a standard button, or must the interface match our brand exactly?
• Where will the API key be stored, and who can see it?
• Which garment types come first, and who owns the size chart for each?

If the answer to the first two is yes, the widget is the quicker pilot. If your brand needs a fully custom interface, plan for the API.

What else should an enterprise team plan for?

Check these before you scope the build:

• Privacy review. Explain what happens to shopper photos. See what to tell shoppers about try-on.
• Staging first. Test with a few products before rollout.
• Image quality. Clean, full-length product photos give better results.
• Ownership. Decide who maintains the key, the size charts and the page code.

We also cover how Google's try-on feature affects stores in Google's virtual try-on for apparel.

FAQs

Is there a ZeDaq.ai cartridge for Commerce Cloud?

No. Use the REST API or the script-tag widget, and have your developers add it to your storefront.

Which is faster to launch?

The widget, because it is one script tag locked to your domain. The API gives more control but takes more build time.

Can I test it before committing?

Yes. The Free plan lets you test, and every paid plan has a 3-day free trial with no card required.

Does my team need a separate sandbox?

Use a staging site and a test key. Lock the key to the domain you are testing on.