CAST Highlight – API rate limits

Effective date: October 1, 2026

Overview

Starting October 1, 2026, CAST Highlight will apply a rate limit to API traffic at the web application firewall (F5) layer: 10 requests per minute, per source IP address, for calls made directly against the public REST API. Interactive, first-party clients — the CAST Highlight web application (used through your browser), is exempt from this limit. Any other caller of the REST API, including custom scripts, CI/CD integrations, and third-party tools, is subject to the limits listed below.

Why we’re introducing rate limiting

CAST Highlight is a multi-tenant SaaS platform: the infrastructure that serves your portfolio’s analysis, dashboards, and integrations is shared across every customer. A rate limit at the WAF layer is a standard safeguard for platforms like this, and it exists to protect the experience of everyone using the platform, including you:

• Predictable performance for all tenants. Without limits, a single script making rapid, unthrottled calls (often unintentionally, e.g. a polling loop with no delay) can consume a disproportionate share of API capacity, slowing down response times for every other customer sharing that infrastructure.
• Resilience against runaway or misconfigured clients. A bug in a script, an infinite retry loop, or an integration that fires on every event without batching can turn into an accidental denial-of-service against our own platform. Rate limiting catches this at the edge before it affects backend services.
• Protection against abuse and credential misuse. Rate limits are also a first line of defense against automated scanning, credential stuffing, or scraping attempts.
• More predictable capacity planning. Bounding the maximum request rate per IP lets us reason about worst-case load on shared services (search indexing, portfolio computation, CVE matching, etc.) and keep those services stable as our customer base grows.

In short: the limit is not about restricting legitimate use, it’s about making sure that one integration’s traffic pattern can’t degrade the platform for others. The 10 requests/minute threshold is set well above what normal interactive or well-designed automated use requires; it’s aimed at catching unthrottled loops and bulk scripting patterns, not routine API calls.

What’s affected

The limit is applied per source IP address, not per API token or per user. If multiple scripts, services, or users share an egress IP (for example, behind a corporate NAT gateway or a shared build server), their combined request volume counts against the same 10 requests/minute budget.

What happens when the limit is exceeded

Once a source IP exceeds 10 requests within a rolling one-minute window, F5 will reject further requests from that IP with an HTTP 429 (Too Many Requests) response until the window resets. We recommend your client also honor a Retry-After header when present, which indicates how many seconds to wait before retrying.

Handling 429 responses in your scripts

If you call the CAST Highlight REST API directly from scripts, integrations, or pipelines, we recommend building in two things: client-side throttling to stay under the limit in the first place, and retry-with-backoff logic to handle the occasional 429 gracefully.

1. Throttle proactively. Pace your calls so you don’t exceed 10 requests per minute (i.e., no more than roughly one request every 6 seconds) rather than bursting and waiting to be rejected.

2. Retry with backoff on 429. When you do receive a 429, back off and retry rather than failing immediately or retrying instantly (which just extends the throttling window).

Example in Python, using requests:

import time
import requests

def call_highlight_api(url, headers, params=None, max_retries=5):
    backoff = 5  # seconds, initial backoff
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params)

        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", backoff))
            print(f"Rate limited. Waiting {retry_after}s before retrying "
                  f"(attempt {attempt + 1}/{max_retries}).")
            time.sleep(retry_after)
            backoff = min(backoff * 2, 60)  # exponential backoff, capped
            continue

        response.raise_for_status()
        return response.json()

    raise RuntimeError("Exceeded max retries after repeated 429 responses.")

Equivalent shell/curl pattern:

#!/usr/bin/env bash
url="$1"
max_retries=5
wait=5

for i in $(seq 1 $max_retries); do
  status=$(curl -s -o response.json -w "%{http_code}" "$url" -H "Authorization: Bearer $TOKEN")
  if [ "$status" -eq 429 ]; then
    echo "Rate limited, waiting ${wait}s..."
    sleep "$wait"
    wait=$((wait * 2))
  else
    cat response.json
    break
  fi
done

3. Batch where possible. If your integration currently makes many small, individual calls (e.g., one request per application per loop iteration), check whether the API offers a batch or bulk endpoint to reduce total request count instead of relying purely on retries.

4. Cache results you don’t need in real time. For data that doesn’t change minute-to-minute (portfolio configuration, historical scan results), cache locally rather than re-fetching on every run.

Frequently asked questions

Does this affect the CAST Highlight web UI or CLI?
No. Both are recognized as first-party clients and are exempt from the limit.

Does this affect the MCP Server?
No. Requests made through the CAST Highlight MCP Server are exempt from this limit.

What if my team shares an IP address (VPN, NAT gateway, shared CI runner)?
The limit is applied per source IP, so all traffic from that shared IP is counted together. If this is likely to affect you, consider running scheduled/batch jobs from distinct egress IPs, or contact support to discuss your integration’s needs.

What if I need a higher limit for a legitimate use case?
Reach out to your CAST Highlight account team or support to discuss your integration pattern; exceptions can be evaluated case by case.