wc_batch_update_variations: change variations in bulk

Applies updates to several variations in one call. It is a loop around wc_update_variation, not a transaction.

Arguments

Each entry accepts the same fields as a single variation update: sku, regular_price, sale_price, description, stock_quantity, attributes.

Permissions and preflight

The WooCommerce write gate, OAuth write scopes and editing permissions for every variation and parent product are required. Supply 1–50 rows with unique IDs. Malformed rows and row-level transport controls are rejected on both transports; put dry_run on the batch only. All rows are validated before requesting approval.

Inspect completion

A successful response contains complete: true and every saved result. If execution fails after changes begin, the operation stops and returns complete: false, completed results, failed_id and error. Earlier changes remain saved. Inspect the affected products before requesting another operation; there is no automatic rollback.

Preview the whole batch first

With dry_run at the batch level you get a before and after for every entry:

Dry-run the batch and show me a table of every variation, its current price and its new one.

That table is the review step. It exposes the entries that would not change anything, the ones already on sale, and any ID that does not resolve.

Read the current state before building the batch

There is no revision history. The list from wc_get_product_variations, read before the batch, is your only restore path.

List every variation of product 219 with its prices and stock, then build the batch.

Keep that listing. If the batch goes wrong, you rebuild from it — as another batch.

Percentage rules need a decision about sales

"Raise all variations by 10%" is ambiguous when some are on sale. Raising regular_price on a discounted variation changes nothing customers see; raising sale_price deepens the discount's confusion.

Decide before the batch is built:

Raise regular_price by 10% on the variations that are not on sale, and list the ones you skipped.

Size the batch to what you can check

The batch is convenient, and that is the risk: one call can change every combination of a product, publicly, with no undo.

Start with two or three entries, verify the storefront, then run the rest. The maximum is 50 variations per batch.

After writing

1. Walk the results list and account for every entry.
2. List the variations again and compare against your pre-batch table.
3. Open the product page and select two or three affected combinations.
4. Check the product's price range on listing pages.
5. Purge the cache, then the CDN.

Common problems

Related

• wc_update_variation — the single-item form
• wc_get_product_variations — read before, compare after
• Manage product variations