Bulk supplier onboarding API fails with 504 Gateway Timeout on large CSV uploads

We’re implementing automated supplier onboarding and hitting serious timeout issues with the REST API. When uploading supplier lists with more than 200 records via CSV, the bulk upload endpoint consistently returns 504 Gateway Timeout after exactly 60 seconds. The API gateway timeout settings appear to be the bottleneck, but I’m not sure if that’s the only issue.

Our current approach:

POST /Windchill/servlet/odata/SupplierMgmt/BulkImport
Content-Type: multipart/form-data
file: suppliers_batch_500.csv (500 records)

Smaller batches (under 150 records) complete successfully in 30-45 seconds, but our typical onboarding needs are 500-1000 suppliers at once. The server-side processing constraints seem to be the real issue since the method server CPU spikes to 95% during these operations.

Has anyone optimized bulk supplier imports in 11.2? We need to handle large volumes without breaking the upload into tiny batches manually.

Here’s a comprehensive solution addressing all three constraint areas:

1. Bulk Upload Endpoint Limits

The BulkImport endpoint in Windchill 11.2 has undocumented but real limits. PTC’s internal recommendation is 100 records per synchronous API call. Beyond that, you encounter:

  • Transaction timeout limits (180s default in wt.properties)
  • Memory allocation issues for large result sets
  • Database lock contention

The proper approach is implementing client-side batching:

// Pseudocode - Key implementation steps:
1. Read CSV file and split into chunks of 100 records each
2. For each chunk, create separate multipart request
3. POST to /SupplierMgmt/BulkImport with chunk data
4. Collect response IDs and track success/failure per chunk
5. Implement retry logic for failed chunks with exponential backoff
// See documentation: Windchill REST API Guide Section 8.4

This keeps each transaction under 30-45 seconds and prevents resource exhaustion.

2. API Gateway Timeout Settings

Your 60-second timeout is at the HTTP server level (Apache/IIS), not Windchill. While you can increase it, that’s treating symptoms not root cause. Proper configuration:

  • HTTP Server: Increase timeout to 120s as safety buffer for legitimate operations
  • Method Server: Verify wt.method.server.requestTimeout=180000 (180s) in wt.properties
  • Database: Check connection timeout settings in wt.properties: wt.pom.dbcp.maxWait=120000

However, even with generous timeouts, processing 500 suppliers synchronously is architecturally wrong. You need asynchronous processing:

Asynchronous Pattern (Recommended):

// Pseudocode - Key implementation steps:
1. Create custom REST endpoint that accepts full CSV file
2. Store file temporarily and return job ID immediately (< 2s response)
3. Queue background task using Windchill QueueManager
4. Process CSV in background with 100-record batch commits
5. Provide status endpoint: GET /SupplierMgmt/BulkJobs/{jobId}
// See documentation: Windchill Customization Guide Chapter 12

This pattern decouples upload from processing, preventing all timeout issues.

3. Server-Side Processing Constraints

The 95% CPU spike indicates inefficient processing. The OOTB bulk endpoint creates each supplier individually within a single transaction, causing:

  • Linear performance degradation (each record takes longer than previous)
  • Database table locks held for entire transaction duration
  • Memory accumulation for validation results

Optimization strategies:

  • Enable batch SQL inserts: Set wt.pom.dbcp.defaultBatchSize=50 in wt.properties
  • Increase method server heap if consistently processing large batches: -Xmx8g minimum
  • Disable unnecessary event listeners during bulk operations (if you have custom listeners on supplier creation)
  • Use database connection pooling: wt.pom.dbcp.maxActive=100

Practical Implementation for Your Use Case:

For 500-1000 supplier onboarding:

  1. Client-side chunking (immediate solution):

    • Split CSV into 100-record chunks
    • Submit sequentially with 2-second delays between batches
    • Track failures and retry
    • Total time: ~8-10 minutes for 1000 suppliers (acceptable for batch onboarding)
  2. Server-side async processing (better long-term):

    • Develop custom REST endpoint using Windchill QueueManager
    • Accept full CSV, process asynchronously
    • Provide job status polling endpoint
    • Send email notification on completion

Testing recommendations:

  • Monitor method server metrics during bulk operations: CPU, memory, DB connections
  • Check MethodServer.log for transaction timeout warnings
  • Verify no deadlocks in database during parallel processing
  • Load test with concurrent bulk operations to ensure stability

The 100-record batch size isn’t arbitrary - it’s based on typical supplier attribute complexity and database transaction overhead. If your supplier records are minimal (few attributes), you might push to 150 per batch, but 200+ will always risk timeouts regardless of configuration tuning.


This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

The 60-second timeout is your HTTP server configuration, not Windchill. Check your Apache or IIS timeout settings - default is usually 60s. However, even if you increase that, processing 500 suppliers synchronously will still overwhelm the method server. You need an asynchronous approach where the API accepts the file and returns immediately, then processes in background.

The bulk upload endpoint in 11.2 has hard limits. From PTC documentation, the recommended batch size is 100 records per API call. Beyond that, you’re fighting against transaction timeout limits and memory constraints. The endpoint wasn’t designed for true bulk operations - it’s more of a convenience wrapper around individual creates. You should implement chunking logic in your client code to split the CSV into 100-record batches and submit them sequentially or with controlled parallelism.

Tested this on Windchill 11.2 with a 50,000-row supplier CSV—chunking into 100-record batches via the BulkImport endpoint eliminated our 504 timeouts completely.

I was hoping to avoid client-side chunking since we have multiple integration points that would need the same logic. If I do increase the HTTP timeout to say 300 seconds, would that be sufficient for 500 records? Or are there other server-side processing constraints that would still cause failures?

Increasing HTTP timeout won’t solve this. The real constraints are: 1) Method server transaction timeout (default 180s), 2) Database connection pool exhaustion under heavy load, and 3) Memory pressure from holding large result sets. Even if your HTTP call doesn’t timeout, the backend transaction will. I’ve seen method servers crash trying to process 500+ suppliers in one transaction. You absolutely need batching, but you can implement it server-side with a custom REST endpoint that accepts the full file, queues it, and processes asynchronously.

We faced this exact issue last quarter. Even with timeout adjustments, bulk operations lock database tables and cause contention for other users. The API gateway timeout settings are actually a safety mechanism preventing runaway transactions. Consider using Windchill’s built-in bulk loading utilities instead of REST API for initial supplier onboarding. They’re designed for volume and run as background tasks.

There’s also the network layer to consider. If your CSV file is large, the upload itself consumes time before processing even starts. With 500 suppliers and typical attribute counts, you’re looking at 2-3 MB files. Over slower networks, that’s 10-15 seconds just for upload. Combined with processing time, you’re guaranteed to hit timeouts. Compression can help but doesn’t solve the core issue.