How to Cache Try-On Results Without Keeping Photos Too Long

To cache try-on results safely, store only the rendered image, tie it to one shopper session and one product, give it a short expiry, and never keep the shopper's original photo. Delete the cache entry when the session ends or when the shopper asks you to.

This guide is for developers who call a try-on API from their own backend. The wider picture is in the virtual try-on API for ecommerce developers. It is general engineering advice. It isn't legal advice, and it doesn't describe how ZeDaq.ai stores data internally.

Why cache try-on results at all?

A render takes time and, on most plans, counts against a monthly allowance. Per the ZeDaq.ai API reference, a call to POST /api/v1/tryon costs one try-on. If a shopper refreshes the page or flips between tabs, you don't want to render the same image twice.

Caching gives you two things:

• Speed: the shopper sees the image instantly when they return to it.
• Fewer repeat calls: the same result is reused instead of paid for again.

The risk is that a cache is a second place where personal images live. So the aim is to cache the minimum, for the shortest time.

What should you cache, and what should you never store?

Separate the input from the output.

Item	Cache it?	Why
Rendered try-on image	Yes, briefly	It is the result you want to reuse
Shopper's original photo	No	It is the most sensitive item
Product image	Yes	It is your own catalog data
Size recommendation result	Yes, briefly	It is small and quick to reuse
API key	Never in a cache or browser	Keep it on your server

If you must hold the original photo for a moment to send the request, keep it in memory and let it go once the call returns. Don't write it to disk or logs.

How should you build the cache key?

A good key makes sure one shopper never sees another shopper's image. Combine:

1. A session ID that is random and not tied to a name or email.
2. The product ID or the product image URL.
3. The garment type, since the API accepts upper_body, lower_body or dresses.
4. A version that changes if you replace the product image.

Don't use a hash of the shopper's photo as the only key. It can identify the same person across sessions, which is exactly the tracking you want to avoid.

How long should the cache last?

Keep it as short as the use case allows. A safe default is the length of the shopper's visit, with a fixed expiry as a backstop.

Pick a time to live (TTL), meaning the time before an entry deletes itself. Many stores choose minutes or hours, not days. Decide your own value and write it in your privacy policy.

Set expiry on the cache itself, not in a cleanup job you may forget. Most key-value stores, such as Redis, support per-key expiry.

How do you handle the 202 response?

The try-on endpoint can return a result straight away or tell you the render is still running. The API reference says a 202 response includes a poll_url, which you poll until it returns the image.

Only cache once you have a final image. Don't cache a pending job as if it were a result. Also, don't cache error responses, such as tryon_cap_reached, because the shopper may succeed later.

How do you let shoppers delete their data?

Make deletion simple:

• Provide a "Remove my image" button next to the result.
• Delete the matching cache entry when it is pressed.
• Clear all entries for a session when the visit ends.
• Keep your own logs free of image data.

Explain in plain words what you store and for how long. The article on what retailers should explain about shopper privacy and virtual try-on covers wording for product pages.

For laws that apply to you, such as data-protection rules in your country, read the official regulator's guidance. Your obligations depend on where you and your shoppers are.

How do caching and image quality fit together?

Caching won't fix a poor result. The quality of a render depends on the images going in. If you are choosing between product photo types, see flat-lay vs model shots for better try-on results. If you are planning the whole rollout, how long it takes to launch virtual try-on gives a realistic timeline.

If you run WooCommerce, the virtual try-on setup for WooCommerce shows the no-code route, and the widget handles the request for you.

FAQs

Is it safe to cache the shopper's uploaded photo?

It is better not to. Keep the original photo in memory only for the request, and cache just the rendered result for a short time.

Can I cache results across different shoppers?

No. A try-on image shows one person. Key every entry to a single session so it can't be shown to anyone else.

How long should I keep cached renders?

As short as your use case allows. Use the length of the visit as a guide, and set an expiry on the cache so entries delete themselves.

Does caching reduce my API usage?

It can, because a reused result avoids a second render. The API reference says a try-on call costs one try-on, so avoiding repeat calls saves allowance.