ERP API Rate Limits Comparison: Salesforce vs SAP vs Oracle vs NetSuite vs Dynamics 365 vs Workday (2026)

TL;DR

• Bottom line: Rate limit architectures vary dramatically — Salesforce uses hard daily quotas by edition, NetSuite governs by concurrency slots, Dynamics 365 F&O throttles on server resource utilization, SAP delegates to infrastructure, Oracle Fusion caps per-request records, and Workday limits are largely undocumented.
• Key limit: Salesforce Enterprise is the most explicit at 100,000 API calls/24h base + 1,000/user license; all others use some form of fair-use or resource-based throttling.
• Watch out for: NetSuite's concurrency pool is shared across ALL API types (REST, SOAP, RESTlets, SuiteQL) — a heavy SOAP integration can starve REST calls in the same account.
• Best for: Planning integration architecture, capacity planning, and selecting the right ERP API surface for your data volume.
• Authentication: All six systems support OAuth 2.0; rate limits are typically tracked per authenticated user or service principal, not per endpoint.

System Profile

This card compares API rate limits, throttling mechanisms, and governance models across the six most common enterprise ERP platforms as of early 2026. It covers cloud deployments only — on-premise SAP and Dynamics have different (or no) API throttling models.

API Surfaces & Capabilities

Rate Limits & Quotas

Per-Request Limits

Rolling / Daily Limits

Transaction / Governor Limits

Authentication

Authentication Gotchas

• Salesforce: API calls from Apex triggers inside a transaction count against governor limits, NOT the daily API limit — these are separate quota pools. [src1]
• Dynamics 365: Each web server independently tracks the 6,000 req/5-min limit. With multiple servers, your actual limit is 6,000 x N web servers, but you can't control which server receives your request. [src2]
• NetSuite: All API types (REST, SOAP, RESTlets, SuiteQL) share the SAME concurrency pool. A single heavy SOAP integration can block REST calls for the entire account. [src3]

Constraints

• Salesforce edition lock-in: Developer Edition has only 15,000 API calls/24h while Enterprise has 100,000+ base. Always test with a sandbox from your actual edition. [src1]
• NetSuite shared concurrency: All API types share concurrency slots. Design integrations to reserve dedicated concurrency allocations per integration record. [src3, src8]
• Oracle Fusion 499-record wall: REST API GET requests return max 499 records regardless of limit parameter value. Pagination mandatory. Use FBDI for bulk operations. [src6]
• Dynamics 365 resource-based throttling: Even if user-based limits aren't hit, resource-based limits can throttle when aggregate server CPU/memory exceeds thresholds. [src2]
• SAP no built-in limits: S/4HANA Cloud has no API-level rate limiting — without API Management, a runaway integration can destabilize the entire tenant. [src5]
• Workday opacity: Workday does not publish comprehensive rate limits. Integrations must implement defensive retry logic. [src7]
• Dynamics 365 Dataverse daily limits stack: If a user has multiple D365 licenses, their daily request limits add together. [src4]

Integration Pattern Decision Tree

START -- Which ERP system are you integrating with?
|
+-- Salesforce
|   +-- < 2,000 records/operation? --> REST API (100K calls/24h)
|   +-- > 2,000 records? --> Bulk API 2.0 (15K batches/24h, 150MB/file)
|   +-- Need real-time events? --> Platform Events / CDC (200K events/24h)
|   +-- Governor limits concern? --> Batch Apex (async: 200 SOQL, 60s CPU)
|
+-- SAP S/4HANA Cloud
|   +-- Standard CRUD? --> OData v4 (no hard rate limit)
|   +-- Bulk data? --> $batch requests or IDoc/BAPI
|   +-- Need throttling? --> Deploy SAP API Management layer
|
+-- Oracle Fusion Cloud
|   +-- < 500 records? --> REST API (499 max per GET)
|   +-- > 500 records read? --> REST with offset pagination loops
|   +-- Bulk import? --> FBDI (file-based, no API limit)
|   +-- Bulk extract? --> BI Publisher reports / BIP
|
+-- NetSuite
|   +-- < 1,000 records? --> REST API or SuiteQL
|   +-- Concurrency concern? --> Reserve slots via Integration Records
|   +-- Bulk operations? --> SuiteTalk SOAP with saved searches
|   +-- Need real-time? --> RESTlets (5 concurrent per user max)
|
+-- Dynamics 365 F&O
|   +-- Standard CRUD? --> OData v4 (6,000 req/5min/user/server)
|   +-- Bulk import/export? --> DMF (exempt from API limits)
|   +-- High volume real-time? --> Dual Write or Virtual Entities
|   +-- Dataverse (CE)? --> 40,000 req/24h per licensed user
|
+-- Workday
    +-- Standard CRUD? --> REST API (limits undocumented)
    +-- Report extraction? --> RaaS (up to 2GB per report)
    +-- Bulk query? --> WQL (Workday Query Language)
    +-- Always implement --> Retry logic with exponential backoff

Quick Reference

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Salesforce sandbox gives false confidence: Developer/sandbox orgs have 15,000 API calls/24h vs 100,000+ in Enterprise production. Fix: Test against a full-copy sandbox provisioned from your actual production edition. [src1]
• NetSuite SOAP starves REST: Heavy SOAP XML payloads hold concurrency slots longer than lightweight REST calls. Fix: Reserve dedicated concurrency per integration record; migrate SOAP to REST where possible. [src3]
• Dynamics 365 multi-server confusion: The 6,000 req/5-min limit is per web server, and requests are load-balanced. Fix: Start at 1,200 req/min and increase until 429 errors appear, then use Retry-After intervals. [src2]
• Oracle Fusion silent pagination failure: Setting limit=1000 silently returns only 499 records without error. Fix: Always check the hasMore attribute; loop with offset pagination. [src6]
• SAP no limits until everything breaks: Without API Management, a runaway batch job can consume all dialog work processes. Fix: Deploy SAP API Management with spike arrest and quota policies before production. [src5]
• Workday undocumented limits cause surprise failures: Integrations that work in testing hit undiscovered rate limits at production scale. Fix: Always implement retry with exponential backoff; contact Workday support for tenant-specific limits. [src7]

Anti-Patterns

Wrong: Assuming all ERPs have the same rate limit model

// BAD -- treating all ERPs like Salesforce with a single daily counter
const MAX_DAILY_CALLS = 100000; // This is Salesforce-specific!
let callCount = 0;

async function callErpApi(erpSystem, endpoint) {
  if (callCount >= MAX_DAILY_CALLS) {
    await waitForReset();
  }
  callCount++;
  return fetch(endpoint);
}

Correct: System-specific rate limit handling

// GOOD -- each ERP has its own throttling model
const rateLimitStrategies = {
  salesforce: { type: 'daily_quota', limit: 100000, window: '24h' },
  netsuite:   { type: 'concurrency', maxSlots: 15, retryOn: [429, 403] },
  dynamics365: { type: 'sliding_window', limit: 6000, window: '300s' },
  oracle_fusion: { type: 'fair_use', retryOn: [429] },
  sap:        { type: 'infrastructure', managed: 'api_management' },
  workday:    { type: 'undocumented', retryOn: [429] },
};

async function callErpApi(erpSystem, endpoint) {
  const strategy = rateLimitStrategies[erpSystem];
  try {
    return await fetchWithRetry(endpoint, strategy);
  } catch (e) {
    if (strategy.retryOn?.includes(e.status)) {
      const retryAfter = e.headers?.get('Retry-After') || 5;
      await sleep(retryAfter * 1000);
      return callErpApi(erpSystem, endpoint);
    }
    throw e;
  }
}

Wrong: Using REST API for bulk data in Oracle Fusion

// BAD -- looping REST calls to import 10,000 records (499 max per request)
for (let offset = 0; offset < 10000; offset += 499) {
  await fetch(`/fscmRestApi/resources/v1/invoices?limit=499&offset=${offset}`);
  // 21 API calls minimum, each potentially throttled
}

Correct: Use FBDI for bulk operations in Oracle Fusion

// GOOD -- use File-Based Data Import for bulk operations
const fbdiPayload = {
  OperationName: "importBulkData",
  DocumentContent: base64EncodedCsv,
  ContentType: "text/csv",
  DocumentAccount: "fin$/journal$/import$"
};
await fetch('/fscmRestApi/resources/v1/erpintegrations', {
  method: 'POST',
  body: JSON.stringify(fbdiPayload)
});

Wrong: Not reserving NetSuite concurrency slots

// BAD -- all integrations compete for the same pool
// Integration A: SOAP sync (holds slots for 5-10s per request)
// Integration B: REST real-time (needs <1s responses)
// Integration C: RESTlet webhooks (blocked by A and B)
// Result: Integration C gets 429 errors during peak hours

Correct: Reserve dedicated concurrency per integration

// GOOD -- allocate slots via NetSuite Integration Records
// Setup > Integration > Integration Management > Integration Governance
// Integration A (SOAP sync): 8 reserved slots
// Integration B (REST real-time): 5 reserved slots
// Integration C (RESTlets): 3 reserved slots
// Unallocated: 1 slot minimum (required by NetSuite)
// Total: 17 slots = Premium tier (15 base + 1 SuiteCloud Plus license)

Common Pitfalls

• Salesforce: Testing on wrong edition: Developer Edition has 15,000 API calls/24h while Enterprise has 100,000+ base. Fix: Always provision a full-copy sandbox from your production org for integration testing. [src1]
• Dynamics 365: Ignoring execution time limit: The 1,200-second combined execution time in 5 minutes is often hit before the 6,000 request count. Fix: Monitor execution time via Dynamics 365 telemetry; simplify OData queries. [src2]
• NetSuite: SuiteCloud Plus math error: Base varies by tier (Standard=5, Premium=15, Enterprise=20). Fix: Check Setup > Integration > Integration Governance for actual account limits. [src3, src8]
• Oracle Fusion: Assuming limit parameter works above 499: Setting limit=1000 silently returns only 499 records. Fix: Always implement pagination with hasMore attribute checking. [src6]
• Cross-platform: Conflating per-org vs per-user limits: Salesforce limits are per-org; Dynamics 365 limits are per-user-per-server; NetSuite limits are per-account. Fix: Read this comparison card before designing multi-ERP integrations.
• SAP: Going to production without API Management: No built-in throttling means no protection against runaway integrations. Fix: Deploy API Management with spike arrest before go-live. [src5]

Diagnostic Commands

# === SALESFORCE: Check remaining API quota ===
curl -H "Authorization: Bearer $SF_TOKEN" \
  "https://yourInstance.salesforce.com/services/data/v62.0/limits" \
  | jq '.DailyApiRequests'
# Returns: { "Max": 100000, "Remaining": 87234 }

# === NETSUITE: Check concurrency governance ===
# Navigate to: Setup > Integration > Integration Management > Integration Governance
# Or use SuiteQL:
curl -X POST "https://ACCOUNT_ID.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql" \
  -H "Authorization: OAuth ..." \
  -d '{"q": "SELECT * FROM integrationGovernance"}'

# === DYNAMICS 365 F&O: Monitor throttling ===
# Check Lifecycle Services (LCS) > Environment Monitoring > Raw Logs
# Filter for: ThrottledRequests

# === DYNAMICS 365 DATAVERSE: Check daily allocation ===
# Power Platform Admin Center > Licensing > Capacity add-ons > Download reports

# === ORACLE FUSION: Test pagination behavior ===
curl -u "user:pass" \
  "https://your-instance.fa.ocs.oraclecloud.com/fscmRestApi/resources/v1/invoices?limit=499&offset=0" \
  | jq '.hasMore'
# If true, increment offset by 499 and repeat

# === SAP S/4HANA: Check API Management metrics ===
# SAP Integration Suite > API Management > Analyze > API Traffic

Cross-System Comparison

When to Use / When Not to Use

Important Caveats

• Rate limits change with every major release. Salesforce updates limits with each seasonal release; SAP with each quarterly update; Dynamics 365 with each 10.0.x version. Always verify against current release notes.
• Salesforce limits vary dramatically by edition — the difference between Developer (15K/day) and Unlimited (5M/day) is 333x. Never extrapolate from one edition to another.
• SAP and Oracle Fusion do not publish hard rate limits. The numbers in this card are derived from official documentation, community resources, and practitioner experience.
• Workday rate limits are the least transparent of all six platforms. The only confirmed per-endpoint limit is 5 req/sec for Strategic Sourcing.
• Dynamics 365 F&O made user-based limits optional (disabled by default) in version 10.0.36 — resource-based limits remain mandatory. [src2]
• NetSuite concurrency governance was introduced in Release 2017.2. The exact per-minute and per-day rate limits are not publicly disclosed. [src3]
• Sandbox and developer environments often have lower limits than production (especially Salesforce and NetSuite). Always validate integration capacity in a production-equivalent environment.