store/generate-variations builds the variations of a variable product from every combination of its varying attributes, skipping any that already exist.
It reports what it would create and changes nothing unless apply is true.
At a glance
| Ability | store/generate-variations |
| Toolset | WooCommerce — toolset/woocommerce |
| Group | WooCommerce › Products & Variations |
| Requires | WooCommerce, active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
The count multiplies
This creates one product per combination, and the count multiplies: three sizes by four colours by five materials is sixty products in one call. Run it without apply first and read the count. A request that times out half way leaves a product that looks finished and is not, with some combinations buyable and some missing.
Why the dry run is the default
The number of variations is the product of the option counts, and people are reliably bad at estimating it. A set that reads as “a few sizes and a few finishes” is routinely forty products, each of which is a real post with its own meta and its own row in the lookup table.
So the default is to report: how many exist, how many would be created, and what they are. Adding apply: true is the second look.
Generation is capped per call. If the cap is hit, the response says so — reduce the options or run it in batches rather than assuming the product is complete.
Existing combinations are skipped rather than duplicated, which makes re-running after a partial run the correct repair.
Variations are created with no price. store/update-variation sets those, and a variation without one cannot be bought.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
id | integer | Yes | Variable product ID. |
apply | boolean | No — defaults to false | Create them. Without this the call only reports what it would do. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
dry_run | boolean | Whether this was a report rather than a change. |
existing_count | integer | How many variations the product already has. |
would_create | array | The combinations that would be created. |
would_create_count | integer | How many that is. |
created | array | What was actually created, when applying. |
note | string | Any cap or partial-run warning. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Build out all the variations for the new t-shirt.
It resolves to one call:
{
"ability": "store/generate-variations",
"parameters": {
"id": 812,
"apply": true,
"confirm": true
}
}Worth knowing
- Run it without
applyfirst. The count is usually larger than expected. - Existing combinations are skipped, so re-running after a partial run is safe.
- Capped per call. A hit cap is reported, not hidden.
- New variations have no price and cannot be bought until one is set.
Related abilities
- Create Variable Product — the first step
- Update Variation — price each combination
- Set Product Attributes — change the axes first
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category