Skip to main content
PATCH /v1/products/bulk applies partial updates to a batch of existing products in a single request. Each item in the batch identifies one product and carries only the fields that changed, so an integration syncing a few attributes across thousands of products no longer has to send a full record per product or fall back to one request per product. Use it when you’re updating products that already exist. To create or fully upsert products, use Bulk upsert products (POST /v1/products/bulk); to change a single product, use Patch a product.

​
Field semantics

Each item updates only the fields it includes:
  • Omitted fields are left unchanged - you don’t need to resend sku_name, current_price, unit_cost, or any other field you aren’t changing.
  • 0 and false are preserved as real values, not treated as empty.
  • An explicit null clears a nullable field; it does not clear non-nullable fields.

​
Per-item outcomes

The batch returns an explicit outcome per item, so a problem with one product doesn’t sink the rest:
  • Missing products - an identity that doesn’t exist in your organization is reported, not created.
  • Invalid changes - a field that fails validation is reported against that item.
  • Duplicate identities - the same product appearing twice in one batch is reported rather than applied twice.
Valid items in the same batch still succeed.

​
Replay and batch size

Replaying the same batch is safe - re-applying an identical partial update is idempotent. Large batches are processed in bounded chunks, so the database work scales with the number of chunks rather than with individual products. Keep each request within the documented batch limit and split larger syncs across several calls; a retried call can repeat a chunk without creating duplicates. Organization isolation and API-key authorization apply exactly as on the other product endpoints: a batch can only read and update products in the authenticated organization.