3792944 - API Rate Limits for SAP SuccessFactors: Frequent Asked Questions

Starting with the 2608 release (August 17, 2026), SAP SuccessFactors applies standardized rate-limit response headers to all API responses for existing tenants.

You may notice new RateLimit-Policy and RateLimit headers in your API responses.

In a later phase, requests that exceed a hard limit will be rejected with HTTP 429 (Too Many Requests).

Reference

• WNV announcement: API Rate Limiting Enhancements and Guardrails | SAP Help Portal 
• Help Portal guide: Rate Limits | SAP Help Portal

SAP SuccessFactors HCM Suite

Summary

Phases dates

General Rate Limit Values

Important notes

• Rate limits apply to all SAP SuccessFactors APIs regardless of module. Entity-specific limits may also apply — refer to the individual API references in the Rate Limits | Help Portal for details.
• Learning OData APIs have separate, pre-existing throttling limits that were in place before this framework. These limits still apply independently. See Throttling Limits for Learning OData APIs and KBA 2516640 for Learning-specific details.

1. What's Changing and When

A standardized API rate-limiting framework, aligned with SAP's API Policy. It introduces two types of enforcement:

Q: Do I need to take action now?

Yes. Even though soft limits do not block your requests, you should:

1. Monitor the RateLimit-Policy and RateLimit headers in your API responses starting now.
2. Inventory all active integrations in your tenant (CPI, Boomi, custom, third-party).
3. Estimate each integration's request volume against the limits above.
4. Optimize any integration that is close to or exceeding the limits — for example, by using delta loads, reducing polling frequency, or consolidating calls with $batch.

2. How Limits Work

Q: At what level are rate limits enforced?

Rate limits are enforced at two levels, and every request must satisfy both:

1. Tenant level — applies to all API requests across your entire tenant, shared by all integrations and users.
2. Resource level — applies to a specific endpoint or API operation (e.g., $metadata, $batch, upsert, SFAPI).

The resource-level limit is checked first, then the tenant-level limit.

Q: Are there user-specific or integration-specific quotas?

No. There are no per-user or per-integration limits. All integrations and users within a tenant share the same quota budget.

Example: If your tenant runs CPI, Boomi, and custom integrations simultaneously, all of them draw from the same 600 requests/minute budget. A spike from one integration can cause HTTP 429 rejections for all others.

Q: Does each paginated request count as a separate API call against the quota?

Yes. Every HTTP request counts as one API call against both the tenant-level and resource-level quotas — including each paginated page. For example, if your query returns 5,000 records with a page size of 1,000, that results in 5 API calls counted against your quota.

This is why optimizing page size and using $filter to reduce result sets is important — fewer pages means fewer calls consumed.

3. Reading the Response Headers

Starting with the 2608 release, every API response includes two rate-limit headers. You should monitor these headers actively — not only when errors occur.

Q: What do the headers look like?

Here is a real example from an OData v2 API response:

RateLimit-Policy: "customized-spike-arrest";q=75;w=60;m=soft, "tenant-quota";q=600;w=60;m=soft
RateLimit: "customized-spike-arrest";r=73;t=26, "tenant-quota";r=598;t=26

Q: What do the parameters mean?

RateLimit-Policy describes the limit rules:

RateLimit shows your live consumption:

Q: How to know if I hit a policy?

1. Find the policy in the RateLimit header where r = 0 — that is the breached policy.
2. Match that policy name to RateLimit-Policy to read its quota (q) and window (w).
3. Check m:
   • If m=hard → your request was rejected (HTTP 429).
   • If m=soft → your request succeeded, but you are at or over the limit.

4. What to Do When You Hit a Limit

Q: What happens when a hard limit is exceeded?

Your request is rejected with HTTP 429 (Too Many Requests). The response includes a Retry-After header telling you how long to wait before retrying.

Q: What happens when a soft limit is exceeded?

Your request is still processed normally. The breach is flagged only in the response headers. Nothing is blocked, but this is a warning that you should reduce your request rate before hard limits take effect.

Q: How should I handle HTTP 429 errors?

1. Read the Retry-After header → wait that many seconds before retrying.
2. If the retry fails again, double the wait time (exponential backoff).
3. Cap the maximum wait at a reasonable value (e.g., 60 seconds).
4. Log and alert after repeated failures so you can investigate the root cause.

Q: Do I need to implement retry logic in CPI or Boomi?

If you are using SAP Integration Suite (CPI) or Boomi with the standard SuccessFactors adapters, no additional retry logic is needed — both platforms already support HTTP 429 and Retry-After handling natively.

For custom integrations or third-party middleware, you must implement retry logic yourself.

Q: How do I request a rate limit exemption?

If your business scenario requires a higher quota than the standard limits, raise an ticket with SuccessFactors support. The support engineer will engage the relevant API engineering team through an incident to evaluate the exemption request.

Note: Exemptions are evaluated on a case-by-case basis and are not guaranteed.

5. Best Practices to Stay Within Limits

• Use delta loads instead of full extractions. Query only records modified since the last run using lastModifiedDateTime filters.
• Reduce polling frequency. Avoid repeating the same query more often than once per hour unless your business process requires near-real-time data.
• Use $batch requests to consolidate multiple operations into a single API call. Note that $batch itself has a 25 requests/minute resource-level limit.
• Use $select to request only the fields you need, reducing server processing time.
• Avoid calling $metadata repeatedly. Cache the metadata response locally and refresh it only when needed. $metadata has a 25 requests/minute limit.
• Distribute load over time. If you run multiple integration jobs, stagger their schedules so they don't all fire at the same time.
• Monitor headers continuously. Don't wait for HTTP 429 errors — track the r (remaining) values in every response to detect when you are approaching the limit.

API rate limit, API rate limit exceeded, HTTP 429, 429 error, 429 Too Many Requests, Too Many Requests, SuccessFactors API, SAP SuccessFactors API, OData v2, OData v4, SFAPI, SOAP API, SCIM, rate limiting, rate limit exceeded, throttling, API throttling, soft limit, hard limit, quota, quota exceeded, tenant limit, tenant quota, resource limit, spike arrest, RateLimit header, RateLimit-Policy header, Retry-After, SAP API Policy, integration, CPI, Boomi, BTP, middleware, pagination, $batch, $metadata, exponential backoff, 2608 release , KBA , LOD-SF-INT-ODATA , OData API Framework , LOD-SF-LMS-ODA , Web Services OData , LOD-SF-INT-API , API & Adhoc API Framework , LOD-SF-INT-EC , Employee Central SFAPI & OData Entities , LOD-SF-RCM-API , Webservices & APIs , LOD-SF-INT-CE , Compound Employee API , How To