Skip to main content

Repeated 429 RESOURCE_EXHAUSTED errors when closing cases via Chronicle API (SOAR integration

  • September 30, 2026
  • 1 reply
  • 20 views

Forum|alt.badge.img+16

Hi all,

We're seeing repeated 429 / RESOURCE_EXHAUSTED errors when our SOAR playbook closes cases via the Chronicle API. Looking for guidance on which quota this is hitting and what a reasonable limit increase request would look like.

Environment:
- Google SecOps / Chronicle SOAR (Siemplify-based)
- Custom integration action that calls cases.executeBulkClose, plus several read calls (get_case, list_custom_fields, get_case_custom_fields, list wall records) per case closure
- Closing cases in batches (currently ~50+ 'Overflow' cases in a single run)

Error returned:
{
  "error": {
    "code": 429,
    "message": "You have reached the maximum allowed quota for this operation. Please wait until the quota is refreshed or reduce API calls rate. You can check your quota limits here: https://console.cloud.google.com/apis/api/chronicle.googleapis.com/quotas",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Questions:
1. Is there a per-method breakdown of Chronicle API quotas (e.g., is listCustomFields limited separately from executeBulkClose), or is this a single project-wide quota across all Chronicle API calls?
2. What's a typical/default quota limit for these operations, and is a quota increase request the recommended path for higher-volume batch case closures, or is there a preferred bulk/batch endpoint we should be using instead?
3. Are there Chronicle API best practices for batch-closing large numbers of cases (e.g., recommended pacing, batch size limits, or a dedicated bulk endpoint that counts differently against quota than repeated single-case calls)?

Any guidance from folks who've hit this at scale, or from the Chronicle team, would be appreciated. Happy to share more logs/config if useful.

Thanks!

1 reply

MitchellR
Forum|alt.badge.img+3
  • Bronze 1
  • September 30, 2026

Hey there, 

To answer your questions:

  1. The quotas are per-method/group per project in GCP, so if you open the link it shared (and go to that page under your BYOP project) you can see the quota per call to see what it is running into. For example, looking at your bulkClose call in my own project, I would see this: 
  2. The quota page will show the exact limits in your own project. The bulk close is the batched endpoint that can take in a list of cases, but it appears you’re leveraging that already. What is resulting in such a backlog of cases needing closure regularly? This could potentially be fixed upstream by tuning the actual detection content to not flood the SOAR with noise if that’s what’s occurring? You can request a quota increase via support, so long as you have valid reasoning behind the ask.
  3. If not being done already, the bigger item to do here would be handling the 429s in the action itself - code a retry and backoff to fit within the range of the expected quota as your project supports. 

Let me know if any of these help!