Bulk pricing upload via API fails with invalid SKU code errors for certain product lines

Attempting to upload 5000+ pricing records via the pricing management API and getting consistent ‘Invalid SKU Code’ errors for about 40% of records. The SKUs are valid in our product master data - I can see them in the Workday UI and they’re active.


POST /pricing/bulk-upload
Error: "SKU ABC-123-XL invalid - not found in product catalog"

The strange part is that some SKUs with identical format work fine while others fail. We’re using standard format ABC-###-SIZE pattern. This is blocking our automated pricing updates that need to run nightly. Has anyone experienced SKU code format validation issues with bulk API uploads or know about product master data sync requirements?

I’ve solved this exact problem for bulk pricing uploads. Here’s what’s happening and how to fix it:

SKU Code Format Validation: Workday’s pricing API validates SKU codes against the product master using the internal Product ID format, not external SKU identifiers. When you pass ABC-123-XL, the API looks for an exact match in the Product_ID field, but Workday stores this as:

  • Product_ID: ABC-123
  • Variant_Code: XL
  • Display_SKU: ABC-123-XL (generated field, not searchable)

Your 40% failure rate corresponds to products with variants. The API can’t find them because you’re searching by concatenated SKU instead of the proper ID structure.

Bulk API Data Upload Solution: Modify your payload structure to separate product and variant:


{
  "pricing_records": [
    {"product_id": "ABC-123", "variant": "XL", "price": 29.99},
    {"product_id": "ABC-123", "variant": "XXL", "price": 32.99}
  ]
}

For products without variants, pass empty string or null for the variant field.

Product Master Data Sync: Before bulk uploads, query the product master API to build a SKU mapping table:

  1. Export all products with GET /products?include_variants=true
  2. Create a lookup map: {“ABC-123-XL”: {“product_id”: “ABC-123”, “variant”: “XL”}}
  3. Transform your pricing data using this map before upload
  4. Cache the mapping and refresh every 6 hours to handle new products

This preprocessing step ensures your SKU references align with Workday’s internal structure. We process 12,000 pricing records nightly using this approach with 99.8% success rate.

The remaining 0.2% failures are usually products marked as inactive or missing the Priceable flag. Add validation to check product status before including in bulk uploads.

For your nightly automation, implement this workflow:

  1. Refresh product mapping cache (if older than 6 hours)
  2. Transform external SKUs to Workday product ID + variant format
  3. Filter out inactive products
  4. Split into batches of 1000 records (API limit)
  5. Upload with retry logic for transient failures

One critical note: If you’re creating new products and immediately pricing them, you MUST wait for the product sync to complete. Use the /products/{id}/status endpoint to verify product is fully synced before attempting pricing upload. The 15-30 minute delay mentioned earlier is real and can’t be bypassed.

Good point about the sync delay. These are existing products though, been in the system for months. I checked and the Priceable flag is set. The pattern I’m noticing is that SKUs with size variants (XL, XXL, SM) fail more often than base SKUs without size suffixes.

This is a common mistake with bulk API data upload. The pricing API expects product references to match the internal product ID structure, not your external SKU naming convention. Run a product export to see how Workday actually stores these records - I bet your variants are in a separate field.

You’ll need to modify your upload logic to split SKU into base product and variant attributes before submitting to the API.