Bulk supply plan upload via REST API fails with 413 Payload Too Large error when exceeding 500 line items

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re trying to automate supply plan uploads using the REST API but hitting 413 errors when uploading files with more than 500 line items. Our current approach sends the entire supply plan JSON in a single POST request to /fscmRestApi/resources/11.13.18.05/supplyRequests. The payload size is around 8MB, and we’ve confirmed that our API payload size limits are set to the default 10MB in the service configuration.

Here’s our request structure:


POST /fscmRestApi/resources/11.13.18.05/supplyRequests
Content-Type: application/json
{
  "items": [ /* 500+ supply plan items */ ]
}

We’ve explored chunked upload strategies but the API documentation doesn’t clearly explain how to implement batch processing for supply plans. Has anyone successfully handled bulk supply plan uploads, or should we be looking at FBDI as an alternative approach for large datasets?

system 2

Let me provide a comprehensive solution addressing all three focus areas:

API Payload Size Limits: Oracle Fusion REST APIs have multiple layers of size restrictions. While your service configuration shows 10MB, the actual runtime limit for supply planning endpoints is approximately 5MB due to internal processing constraints. This isn’t documented but confirmed through Oracle support. Monitor your actual payload sizes - JSON serialization often increases size by 20-30% over raw data.

Chunked Upload Strategies: Implement client-side batching with these parameters:


// Batch configuration
batchSize = 125 items per request
maxPayloadSize = 2MB (safety margin)
retryAttempts = 3
retryDelay = exponential backoff (5s, 10s, 20s)

Process batches sequentially or with controlled parallelism (max 2-3 concurrent). Track batch status in a local database to handle resume scenarios. Implement idempotency by including a unique batch identifier in each request.

FBDI as Alternative: For datasets exceeding 500 items, FBDI is architecturally superior:

  1. Create CSV using supply plan FBDI template (SupplyRequestImportTemplate.xlsm)
  2. Upload to UCM via REST:

POST /fscmRestApi/resources/11.13.18.05/ucmFiles
Content-Type: multipart/form-data
  1. Trigger import job:

POST /fscmRestApi/resources/11.13.18.05/erpIntegrations
{
  "OperationName": "ImportBulkData",
  "IntegrationSystemCode": "SUPPLY_PLAN"
}
  1. Poll job status via ESS REST APIs

FBDI handles 50,000+ rows reliably, provides detailed error logs, and supports concurrent imports. The tradeoff is latency (5-15 minutes for import completion) versus real-time REST validation.

Recommendation: Use REST API batching for up to 500 items when immediate feedback is critical. Switch to FBDI for bulk loads exceeding 1,000 items or when processing overnight. Implement both approaches in your integration layer and route requests based on payload size thresholds.

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

3

The 413 error typically indicates you’re hitting a server-side limit rather than your configured limit. Oracle Fusion REST APIs have undocumented request size thresholds that are lower than the general payload limits. For supply planning, I’ve seen issues around 5-6MB payloads even when limits are set higher.

4

We faced the exact same issue last quarter. The problem is that the supply planning REST endpoints don’t support chunked uploads natively. We had to implement batch processing on our side - splitting the payload into chunks of 100-150 items per request. This kept each request under 2MB and eliminated the 413 errors. You’ll need to add retry logic and track which batches succeeded.

5

Have you considered using FBDI instead? For bulk operations exceeding 200-300 records, FBDI is the recommended approach. It handles larger datasets more reliably and provides better error reporting. The supply plan FBDI template supports tens of thousands of rows without payload issues. You upload the CSV to UCM, then trigger the import process via the ImportBulkData REST endpoint. Initial setup takes longer but it’s more robust for production use.

6

Thanks for the responses. We’re leaning toward implementing batch processing as Maria suggested since we need real-time validation feedback. Could you share what batch size worked best for you? Also, did you implement any specific retry logic for handling partial failures?

robert_user 7

Tested this on Oracle Fusion Cloud 23D and chunking our supply plan payloads into 400-line batches eliminated the 413 errors completely across all REST API calls.

8

From a DevOps perspective, monitor your batch sizes carefully. We found that 100 items per batch with 2-second delays between batches gave us the best throughput without triggering rate limits. Also implement exponential backoff for retries - start with 5 seconds and double on each retry up to 60 seconds max.

9

One thing to watch: ensure your batches maintain referential integrity. If supply plan items reference each other, you need to sequence your batches correctly. We had issues where dependent items were rejected because parent items hadn’t been processed yet in earlier batches.

timothy_tech 10

This kept each request under 2MB and eliminated the 413 errors.