3792944 - FAQ: API Rate Limits for SAP SuccessFactors

SAP has introduced the SAP API Policy(Link), and based on this SAP SuccessFactors will be implementing the API rate limiting across its platform. Starting with the 2608 release (August 17, 2026), soft rate limits and standardized rate limit response headers are being applied to all existing tenants.

This KBA provides answers to the most frequently asked questions about what these changes mean, how they affect your integrations and what actions you need to take.

Disclaimer: Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental. 

• SAP SuccessFactors HXM Core
  
  • API
    • ODATA API
    • REST API
    • SOAP API (Compound Employee)

Q1. What is changing with SAP SuccessFactors APIs?

SAP has introduced a new SAP API Policy to ensure platform stability, reliability, and fair usage across all customers. In alignment with this policy, SAP SuccessFactors is implementing a standardized API rate limiting framework that introduces:

• Soft rate limits for all existing tenants (effective August 17, 2026 — 2608 release)
  
• Hard rate limits for all new public APIs launched from H2 2026 (November 13, 2026 onwards)
  
• Hard rate limits for all new tenants provisioned on or after January 1, 2027

API requests that exceed a hard rate limit will be rejected with an HTTP 429 (Too Many Requests) error response code. Soft rate limit breaches are observed and flagged via response headers but do not block requests.

Q2. Do rate limits apply per user, per integration, or per tenant?

Rate limits are applied at the tenant level (global across all API requests for your tenant, shared by all integrations and users) and at the resource level (per specific endpoint). There are currently no user specific or integration specific rate limits, the entire tenant shares the same quota budget. 

Q3. How do you identify the impact of rate limit policies?

Rate limits are applied at two different scopes to provide granular control over API consumption

• Tenant Level : Tenant-level limits apply globally across all API requests for your tenant, regardless of which specific resources or endpoints are being accessed. They are shared across all integrations and users within the tenant. 
• Resource level : Resource-level limits apply to specific API resources, endpoints, or operations, providing fine-grained control over particular consumption patterns. 

Both scopes are evaluated for every request. A request must comply with both tenant-level and resource-level limits to be processed. Resource-level limits are checked first, followed by tenant-level limits. If either limit is exceeded (in hard mode), the request is rejected.

Q4. How do I identify which rate limit policy was violated when I receive a 429 error?

When a 429 response is returned, examine the `RateLimit` response header. Look for the policy entry where the `r` (remaining) parameter equals 0 — that is the violated policy. Cross-reference it with the `RateLimit-Policy` header to see its configured quota (`q`), time window (`w`), and enforcement mode (`m`).

Example:

RateLimit-Policy: "customized-spike-arrest";q=25;w=60;m=hard, "tenant-quota";q=600;w=60;m=soft
RateLimit: "customized-spike-arrest";r=0;t=28, "tenant-quota";r=200;t=28

In this example, the `customized-spike-arrest` policy (limit: 25 requests/minute) was violated. The `tenant-quota` policy (600/minute) still has 200 requests remaining. Hence once the hard limit is enabled you will not be able to make the API call for this entity for next 28 seconds as after 28 seconds the count resets

Q5. How will existing customers be affected?

Existing customers are not immediately impacted in terms of blocked requests. Here is what changes:

• From August 17, 2026 (2608 release): Soft rate limits are applied. All API requests continue to be processed, but `RateLimit-*` headers are now returned in every API response. You can begin monitoring your usage.
• APIs that already had hard rate limits applied to specific tenants will continue to have those limits enforced.
• In the future (date to be communicated), SAP will convert all soft rate limits to hard rate limits for all customers. Standardized thresholds will be applied consistently across all tenants at that time.

Q6. How will new customers be affected?

Customers with tenants provisioned on or after January 1, 2027 will have hard rate limits enforced from day one. API calls exceeding the defined limits will be immediately rejected with HTTP 429 responses.

Q7. How will new APIs be affected?

All new public SAP SuccessFactors APIs released from H2 2026 (November 13, 2026) onwards will have hard rate limits enforced from launch. Developers building integrations against new APIs must implement proper error handling and retry logic from the start.

Q8. What actions should customers take right now?

SAP recommends the following action items:

Action 1 — Review and reduce API usage (starting August 17, 2026)
Review your current API integration patterns against the rate limit thresholds above. Identify any integrations that may be at risk of exceeding limits. The `RateLimit-*` headers in API responses will help you measure consumption in real time.

Action 2 — Monitor rate limit response headers
Starting with the 2608 release (August 17, 2026), monitor the `RateLimit-Policy` and `RateLimit` headers in every API response. Detailed guidance will be published on the What's New Viewer (WNV) with the 2608 release.

Action 3 — Prepare for hard limits on new APIs and new tenants
If you are building new APIs or integrations (H2 2026) or provisioning new tenants (from January 1, 2027), ensure your integration design accounts for hard rate limits from the outset.

Action 4 — Implement retry logic and backoff strategies
Update your integrations (including BTP applications) to handle HTTP 429 responses gracefully. Implement exponential backoff and respect the `Retry-After` header value returned in hard mode 429 responses. Do not immediately retry rejected requests.

Q9. How can customers measure their current API usage?

Starting August 17, 2026, customers can monitor the `RateLimit` response headers included in every API response to understand real-time consumption against each rate limit policy. For reporting and analytics on historical API usage, SAP is planning to provide detailed guidance on WNV with the 2608 release.

Q10. What is the best practice for implementing retry logic when handling 429 errors?

When an HTTP 429 response is received in hard mode:

1. Do not retry immediately. Read the `Retry-After` header value (in seconds) from the response.
2. Wait the prescribed time before retrying the request.
3. Implement exponential backoff — if subsequent retries also fail, progressively increase wait time between attempts (e.g., 1s → 2s → 4s → 8s).
4. Use jitter (randomized delay) to avoid synchronized retry storms across multiple integration instances.
5. Log 429 responses and monitor them as integration health signals — a high frequency of 429 errors indicates your integration design needs optimization.
6. Design integrations to stay well below hard limits during normal operations — do not design to the ceiling.

Q11. Will there be exemptions for customers during Go-Live or hypercare phases?

Yes. SAP has confirmed that an API Rate Limit Exemption Process will be available, with a clear expiry date, to support customers during special phases such as Go-Live, hypercare, or peak periods. Customers requiring an exemption should contact SAP Support by logging a case under component LOD-SF-INT-API with full details of the business scenario and requested duration.

Q12. What about existing hard rate limits already in place for some tenants?

Some SuccessFactors APIs already had hard rate limits applied to specific tenants prior to this announcement. Those existing hard rate limits remain in effect. When SAP converts all soft rate limits to hard rate limits in the future, the thresholds will be standardized consistently across all tenants.

Q13. Are there API-specific limits beyond the ones listed above?

Yes. The rate limit table in this KBA covers the primary tenant-level and commonly used resource-level limits. SAP Help Portal publishes a full list of 92+ API endpoints with their specific rate limits and enforcement modes. Refer to the [Rate Limits page on the SAP Help Portal](Link) for the complete reference.

Q14. What integration design principles should I follow to stay within rate limits?

• Group your API calls together - Instead of sending many individual requests one by one, combine them into a single batch request where possible. Think of it like ordering multiple items in one delivery rather than placing separate orders for each — it's more efficient and uses fewer of your available requests.
• Don't keep asking for the same data - If your integration frequently reads the same information from SuccessFactors (e.g., configuration data, picklist values), store a local copy and reuse it instead of fetching it from SAP every single time.
• Spread out your scheduled jobs - If you have multiple integrations that run on a schedule, don't set them all to start at the same time (e.g., all at midnight or all at the top of the hour). Stagger their start times so they don't all compete for the same API quota simultaneously.
• Only fetch what has changed - Instead of downloading all records every time your integration runs, configure it to pull only new or updated records since the last run. This dramatically reduces the number of API calls made.
• Stop automatically when errors occur - If your integration starts receiving HTTP 429 (Too Many Requests) errors, it should pause and wait — not keep retrying repeatedly. Continuing to send requests when you're already over the limit will only make things worse.
• Watch your usage before it hits the limit - Each API response tells you how many requests you have remaining in the current window. Monitor this in real time and slow down proactively before you run out — don't wait for a 429 error to react.
• Don't run at full capacity - Design your integration to use no more than 70–80% of the allowed request limit under normal conditions. Leave a buffer for unexpected spikes, retries, or peak activity — just like you wouldn't drive with your fuel gauge always at empty.

Q15.  Do the rate limits apply to Integration Center Jobs?

No, the rate limit will not consider internal Successfactor specific API calls.

Q16. Do the rate limits apply to SAP Integration Suite / BTP-based integrations?

Yes. Rate limits apply at the SuccessFactors tenant level, regardless of where the API call originates — whether from SAP Integration Suite (BTP), third-party middleware, custom applications, or direct API clients. All API calls to SuccessFactors endpoints count toward the tenant's rate limit budget.

BTP-based integrations should implement the retry and backoff handling described above to gracefully manage 429 responses.

https://help.sap.com/docs/successfactors-platform/sap-successfactors-api-reference-guide-odata-v2/rate-limits?locale=en-US&version=2605&ai=true

API rate limit, 429 error, Too Many Requests, SuccessFactors API, OData v2, rate limiting, LOD-SF-INT-API, soft limit, hard limit, RateLimit header, Retry-After, SAP API Policy, integration, BTP, throttling, quota, spike arrest, tenant limit, resource limit, 2608 release , KBA , LOD-SF-INT-API , API & Adhoc API Framework , LOD-SF-INT , Integrations , LOD-SF-INT-ODATA , OData API Framework , Problem

SAP SuccessFactors HCM Core 2605 ; SAP SuccessFactors HCM Suite 2605