Wix Velo: Calling an External API From Your Store

To call an external API from a Wix store, turn on Velo, write a backend function that uses fetch from the wix-fetch module, and keep the API key in Velo's Secrets Manager. Your page code then calls that backend function, so the key never reaches the browser.

This guide is for developers and store owners who write a little code. The pattern is the same one used for virtual try-on on WooCommerce and custom stores, and the example below uses the ZeDaq.ai try-on API.

Why call the API from backend code?

Wix's own documentation says you can use the Fetch API in frontend or backend code, but it is usually best to send requests to external APIs from the backend. Its Velo integration guide gives these reasons:

• Security. APIs that need a key should be called from the backend.
• No CORS problems. Some requests from the browser are blocked by cross-origin rules.
• Less data in the browser. Your backend can return only the fields the page needs.

Wix also says all Wix sites use HTTPS, so you cannot request plain HTTP content from your site code. Use HTTPS endpoints only.

How do you store the API key?

Use the Secrets Manager. Wix describes it as a secure place for API keys and other sensitive values, found in the Settings section of your site's dashboard.

Wix says to use secrets only in backend code and never send them to the frontend. In backend code, import getSecret from wix-secrets-backend and read the value by name. You can read about the Secrets API in Wix's reference.

Deleting a secret or changing its name or value breaks any code that uses it, so rename with care.

What does the backend function look like?

Here is a sketch that sends a try-on request to ZeDaq.ai. The secret is named zedaqKey in this example. Check Wix's current web module documentation for the file name and export rules, because Velo's conventions can change.

import { fetch } from 'wix-fetch';
import { getSecret } from 'wix-secrets-backend';

export async function requestTryOn(personBase64, productImageUrl) {
  const apiKey = await getSecret('zedaqKey');

  const imgRes = await fetch(productImageUrl);
  const productBase64 = Buffer.from(await imgRes.arrayBuffer()).toString('base64');

  // Confirm the base URL in the API reference before you use this.
  const res = await fetch('https://www.zedaq.ai/api/v1/tryon', {
    method: 'post',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': apiKey
    },
    body: JSON.stringify({
      person_image_base64: personBase64,
      product_image_base64: productBase64,
      garment_type: 'upper_body'
    })
  });

  return res.json();
}

This follows the POST pattern in Wix's guide: import fetch, pass an options object with method, headers and body, then read the JSON. Treat it as a starting point and test it before you use it on a live store.

What does the ZeDaq.ai request need?

The try-on endpoint is POST /api/v1/tryon with an x-api-key header. The body takes the shopper's photo and the product image as base64 strings, in JPEG or PNG, and an optional garment_type of upper_body, lower_body or dresses. The full list of fields and errors is in the API reference.

The response has two shapes:

Status	Meaning	What to do
200	Render complete	Show the returned image
202	Render still running	Poll the poll_url every 2 seconds

Keys can be restricted to specific domains, and requests from other origins are refused. If you see a domain_not_allowed error, check the key's domain settings in the dashboard.

How does the page call the backend function?

Your page code imports the backend function and calls it when the shopper acts. The file name and import path depend on how you create the backend file in Velo's code panel, so follow the pattern Wix shows in its web module documentation.

A good flow is:

1. The shopper picks a photo on the product page.
2. Page code converts it to base64 and calls your backend function.
3. The backend calls the API and returns the result.
4. The page shows the returned image, or a friendly message on error.

Resize the photo before you send it. The ZeDaq.ai API docs say a full-length photo around 800 pixels wide works well.

When is the script tag a better choice?

Velo is useful when you want custom logic or your own interface. If you only want buttons on the product page, the no-code route is shorter.

ZeDaq.ai also has a script-tag widget for Wix that adds "Try it on" and "Find my size". The article on virtual try-on options for Wix compares both routes.

What should you check before going live?

• Secrets are backend only. The key never appears in page code.
• Errors are handled. Show a clear message for each error code, not a blank panel.
• Sizes are set up. Your size chart needs to be in the dashboard for size recommendations.
• Options are clean. Your product options should be tidy, as described in Wix Stores product options for sizes.
• Your platform choice fits. If you are still choosing a builder, see Squarespace versus Wix for fashion designers.

If you want to see how the API works on other stacks, the developer guide to try-on APIs covers general integration steps.

FAQs

Can I call an external API directly from Wix page code?

Yes, Wix supports fetch in frontend code, but it recommends the backend for APIs that need a key.

Where do I store the API key in Velo?

In the Secrets Manager, in your site's dashboard Settings. Read it in backend code with getSecret.

Can I call an HTTP URL from Velo?

No. Wix says all its sites use HTTPS, so requests to plain HTTP content fail.

Do I need Velo to add try-on to Wix?

No. The script-tag widget works without Velo code. Use Velo when you want a custom flow.