Requests accepted but throttled
Verdict
When API requests are accepted yet their effects are reduced, delayed, or suppressed, this typically indicates server-side throttling, not a client-side defect.
If responses remain successful while downstream impact degrades under volume or repetition, further client-side optimization rarely restores full behavior.
At this point, continued pressure from the client is optional, not required.
Why This Happens
Many platforms throttle effects, not requests.
Common mechanisms include:
- Execution throttling, where accepted requests are queued or deprioritized
- Behavior-based limits that react to usage patterns rather than raw rates
- Protection of downstream dependencies while keeping the API surface responsive
- Adaptive capacity management that scales impact independently of acceptance
From the client’s perspective, the API “works.” From the system’s perspective, it is actively limiting consequences.
This separation is intentional and opaque.
Where You Can Stop
Once throttling of effects is suspected, you can usually stop:
- Increasing request volume to compensate
- Assuming acceptance implies full execution
- Treating reduced impact as a client logic error
- Adding retries to force throughput
Further effort on the client side often reinforces throttling behavior instead of overcoming it.
What This Page Is Not
This page does not:
- Expose throttling thresholds
- Provide techniques to evade limits
- Suggest pacing or backoff strategies
Its purpose is to clarify when accepted requests do not guarantee proportional outcomes—and when continued client-side effort becomes discretionary.
Acceptance is not execution; understanding that boundary prevents wasted effort.