We’re experiencing significant performance issues when updating prices for our product catalog using the Workday pricing API. Our catalog contains approximately 15,000 SKUs and we need to update prices weekly based on supplier cost changes.
When we submit bulk update requests through the REST API endpoint, the operation times out after processing only 2,000-3,000 items. The incomplete updates are causing pricing inconsistencies in our system.
POST /api/pricing/v1/bulk-update
Payload: 15000 price records
Response: 504 Gateway Timeout (after ~8 minutes)
Partial Success: ~2100 records updated
We’re hitting the bulk update endpoint limits and suspect API rate limiting is involved. Has anyone dealt with batch processing best practices for large-scale price updates in Workday? What’s the recommended approach for handling catalogs of this size?
Had to solve this exact problem last quarter. Your timeout issues stem from violating multiple API constraints simultaneously. Let me address all the key factors:
Bulk Update Endpoint Limits:
Workday’s pricing API has a hard limit of 1000 items per bulk update request, though practical performance degrades after 500 items. Your 15K payload is triggering gateway timeouts because the backend processing can’t complete within the 10-minute timeout window.
API Rate Limiting Strategy:
Implement a chunked approach with these parameters:
Batch size: 500 records per request (sweet spot for performance)
Request rate: Maximum 60 requests/minute (conservative to avoid 429s)
Concurrent connections: Limit to 2-3 parallel streams
Inter-batch delay: 1-2 seconds between submissions
Batch Processing Best Practices:
// Pseudocode - Optimal batch processing:
1. Split 15K records into batches of 500 items
2. For each batch: POST to /api/pricing/v1/bulk-update
3. Implement exponential backoff on failures (1s, 2s, 4s, 8s)
4. Track batch completion in persistent storage
5. Resume from last successful batch on restart
6. Validate full catalog sync after all batches complete
For your weekly updates, this approach processes 15K records in approximately 30-35 minutes with built-in resilience. Also implement health checks between batches to detect API degradation early.
Additional Optimization:
Use the pricing API’s delta update capability if available in your version. Send only changed prices rather than full catalog refreshes. This typically reduces your batch count by 60-70% for weekly updates.
The combination of proper batch sizing, rate limiting, and retry logic should eliminate your timeout issues completely.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen similar timeout issues with large payloads. The Workday pricing API has undocumented limits on batch sizes. Try breaking your 15K records into smaller chunks of 500-1000 records per request. This prevents gateway timeouts and gives you better error handling granularity.
The batch size recommendation is good, but you also need to implement proper retry logic with exponential backoff. Workday’s API rate limits are per tenant and can vary. I’d suggest adding a 2-3 second delay between batch submissions to avoid triggering rate limiters. Also, check your API client logs for any 429 (Too Many Requests) responses that might be getting swallowed by your timeout handling.
Thanks for the suggestions. We haven’t seen explicit 429 errors in our logs, just the 504 timeouts. Is there a way to query Workday for the current rate limit thresholds for our tenant? We’re on wd-r1-2024 if that matters for API behavior.
Tested this on our 22K-item catalog using 500-record chunks against Workday’s pricing API and eliminated gateway timeouts completely within the first deployment.
Rate limit thresholds aren’t exposed via API unfortunately. You have to work with Workday support to get those details. However, I’ve found that staying under 100 requests per minute and 1000 records per request works reliably across most tenants. For your 15K catalog, that’s 15 batches with built-in breathing room. Also consider running updates during off-peak hours when API contention is lower.
One thing nobody mentioned yet is the importance of idempotency in your batch processing. If a batch partially fails or times out, you need to safely retry without creating duplicate updates. Make sure your implementation tracks which batches completed successfully and can resume from failures. We use a state table to track batch progress with unique batch IDs.