2749091 - COE_SNAPSHOT_BAD_REQUEST error - Protection Mechanism of Snapshot Pagination

Symptom

When calling SuccessFactors APIs using OData API protocol, you are facing a COE_SNAPSHOT_BAD_REQUEST error code with the message below:

"We have temporarily blocked the snapshot pagination request from companyUser <Company ID>|<API_USER> for entity <Entity_Name> until <Time Stamp for block time period> because too many consecutive requests have been attempted without accessing subsequent data. Please retry after you're unblocked and use $skiptoken to fetch the data of subsequent pages, otherwise you will continue getting the first page and be blocked again."
"We have temporarily blocked the snapshot pagination request from companyUser <Company ID>|<API_USER> for all entities until <Time Stamp for block time period> because too many consecutive requests have been attempted without accessing subsequent data. Please retry after you're unblocked and use $skiptoken to fetch the data of subsequent pages, otherwise you will continue getting the first page and be blocked again."

Environment

SAP SuccessFactors HCM Suite

Cause

To safeguard SuccessFactors API servers from excessive or unintended bad requests, a protection mechanism was introduced in the Q1 2019 Release. This feature regulates the use of snapshot-based pagination (paging=snapshot) to ensure efficient resource usage and maintain system performance, preventing abuse or inefficient usage of snapshot-based pagination.

A quota system is enforced at two levels:

Company user level – the API user across all entities
Entity level – the specific entity being queried

If the quota is exceeded, the system blocks further requests for 30 minutes.

Quota Summary:

Feature Behavior and Notes

Multiple bad requests on different entities count individually at the entity level, but collectively as one per entity at the company user level.
Using $skiptoken to retrieve the next page resets the bad request count.
If blocked at the entity level, the user can still access other entities.
If blocked at the company user level, the user cannot access any entities within the company.

Special Considerations for MDF Entities

MDF Foundation Objects support paging=snapshot.
Some entities use a custom header X-SF-Paging to enable fallback from snapshot to offset pagination.
MDF does not support this fallback mechanism and only works with paging=snapshot.

Example

A user sends 3 bad requests on entities A and B, and 2 more on entity C:

Company user level count: 3
Entity level counts:
- A: 1
- B: 1
- C: 2

If the user successfully requests the second page of entity C using $skiptoken, the counts become:

Company user level: 0
Entity level:
- A: 1
- B: 1
- C: 0

Resolution

All integrations failing with Bad Request (400) when calling SuccessFactors with the same API user need to be considered in this case:

Suspend their schedules.
Identify and fix the root cause of the consecutive Bad Request (400) errors. More details are available in the SuccessFactors OData API Audit Logs (step-by-step in KBA 3141692).
Ensure the client system calling SuccessFactors is correctly querying subsequent data (pages) using $skiptoken. Depending on the client system, this may be handled internally (e.g., in CPI).
Wait for the 30-minute block before testing and running them again.
Run the integrations manually to validate after applying the fix.

Additionally, to avoid exceeding quotas, it is recommended to:

Use separate API users for different client systems (e.g., one API user for CPI, another for ERP, etc.).
Avoid running multiple integrations simultaneously with the same API user.

Keywords

company id, blocked, COE_SNAPSHOT_BAD_REQUEST, paging, snapshot, responseCode, 400, bad request,Protection, Mechanism, Pagination paging=snapshot,q12019,protection mechanism of snapshot,coe_snapshot_bad_request , KBA , LOD-SF-INT-ODATA , OData API Framework , Problem

Product

SAP SuccessFactors HCM Suite all versions