Stock availability

How to show what a customer can buy and when: stock, "available within x days", ordered goods with restock dates and the lead time. All values come from Vario and are synchronized every 15 minutes.

The three quantities

Quantity	Meaning	Variation	Product
In stock	physically in the warehouse	stock_state	stock_state = sum over active variations
Available within x days	not in stock, but deliverable within the lead time	expected_count, date expected_date_min, days additional_data.available_lead_time_days	expected_count = sum, expected_date_min = earliest, available_lead_time_days = smallest – all over active variations
Ordered	ordered from the supplier, arrives on a restock date	embed expected_restocks	embed expected_restocks = sums over active variations per date

Only active variations count

Product values are computed from active (published) variations only. An inactive variation is not sellable, so its stock, quantities, lead time and restocks are left out. The variation's own values are always its own, whatever its activity.

Where the values come from

Vario sends one product with its variants (SyncProductsFromVarioScheduledJob, every 15 minutes):

Vario field (variant)	API value
published	variation is_active
quantityInStock	variation stock_state (and stock_states of the default stock)
quantityAvailable	variation expected_count
availableLeadTimeDays	variation additional_data.available_lead_time_days (only when Vario sends it)
sync time + availableLeadTimeDays (5 when missing), 06:00	variation expected_date_min, only when expected_count > 0
quantityIncoming[] {date, quantity}	variation expected_restocks items

After the variants the product values are aggregated from the active variations. They are also recomputed without a sync when a variation is published, unpublished, moved to another product or deleted in the admin.

Getting the data

Product detail – variant picker

Two requests, no per-variant calls:

GET /api/v0/products/71?embed=product_availability,additional_data,expected_restocks

GET /api/v0/product-variations?filters=<base64>&paginate=0&embed=product_availability,additional_data,expected_restocks,properties

with filters = base64 of [{"f":"product_id","o":"eq","v":71}] (see filters).

For the selected variation show each quantity separately:

1. In stock – stock_state.
2. Available within x days – expected_count; the days are _embedded.additional_data.available_lead_time_days, the date is expected_date_min.
3. Ordered – _embedded.expected_restocks.items (date and count), total total_count.

The product values (step 1 request) are the summary before a variation is picked.

Product listing – category, search

Listings use POST /api/v0/products/filter with the shopfront URL; add the product fields you need:

POST /api/v0/products/filter?embed=urls,default_image_url,computed_taxed_prices,product_availability,expected_restocks
Content-Type: application/json

{ "request_uri": "/obleceni/tricka" }

"Available up to N pcs" = stock_state + expected_count of the product (already summed over the active variations). Add expected_restocks.total_count if ordered goods should count too.

The embed is loaded with one query for the whole page.

Bulk variant order

One request for all variations of the product with everything needed for the priority 1. in stock, 2. available within x days, 3. ordered with a restock date:

GET /api/v0/product-variations?filters=<product_id eq 71>&paginate=0&only=id,code,stock_state,expected_count,expected_date_min&embed=expected_restocks,additional_data,properties

Per variation: stock_state → expected_count (+ available_lead_time_days) → expected_restocks.items.

Product comparison

The comparison loads the list items with the product embedded; add expected_restocks to the nested embeds to get the "Objednáno" (ordered) row:

GET /api/v0/customer-product-lists/{listId}/items?per_page=100&embed=product{_embed{product_availability,computed_prices,properties,expected_restocks}}

• Stock + available within x days: product stock_state, expected_count.
• Ordered: product _embedded.expected_restocks.total_count (or the items with dates).

Cart

The cart today allows ordering up to stock_state - reserved_state of the variation. Ordering "available within x days" or ordered goods is not supported yet (separate task).

Lead time

available_lead_time_days is an additional data value:

Where	Value
variation additional_data.available_lead_time_days	as sent by Vario; null when Vario has never sent it
product additional_data.available_lead_time_days	the smallest value among active variations that have one; null when none has it

Notes:

• 0 is a real value from Vario (e.g. product 71 locally has 0 on all variants) and differs from null.
• When Vario sends no lead time, the variation's expected_date_min is still computed with 5 days, but available_lead_time_days stays null (or keeps the last value Vario sent).
• Prefer expected_date_min for a date and available_lead_time_days for an "x days" text.

Restocks

"expected_restocks": {
  "items": [
    { "datetime": "2026-05-06T00:00:00+0000", "count": 70000 },
    { "datetime": null, "count": 120000 }
  ],
  "total_count": 190000
}

• Sorted by date, items without a date last.
• On a product, items with the same date (including "no date") are summed over the active variations.
• Past dates are passed through as Vario sends them (not filtered).
• No restocks → { "items": [], "total_count": 0 }.

Older endpoints

GET /api/theme/product-variations/{id}/expected-restocks and GET /api/theme/product-variation-expected-restocks return the raw restock rows of variations (including inactive ones). They stay for compatibility; new code should use the expected_restocks embed, which needs no extra request.

Data freshness

• Vario values are at most ~15 minutes old.
• Admin changes of a variation's activity, product or deletion recompute the product immediately.
• Product search results come from Elasticsearch, which is reindexed after product changes.