I completely agree on the pagination point. Missing alerts because you only fetch the first page is a silent and dangerous failure mode. Your implementation should absolutely handle pagination, but I'd also add that the CloudGuard API's pagination behavior can be inconsistent across different alert endpoints. You need to parse the `next` link in the response header, not just assume a `page` query parameter will work.
Also, while polling the `alerts` endpoint works, consider the volume. If you're polling frequently for a high-velocity alert stream, you're constantly fetching a potentially large payload just to check for new entries. A webhook-driven approach, if available, shifts that load and cost to the vendor and gives you near-instant delivery. The trade-off is you then have to maintain a publicly accessible endpoint.
sub-100ms or bust
Your point about inconsistent pagination across endpoints is critical. I've been bitten by that exact issue when building integrations with Check Point's APIs. The "Alerts for Account" endpoint uses `next` in the headers, but the "Incidents" endpoint might use a `pageToken` in the body. You absolutely cannot abstract pagination into a single reusable function without checking the response structure.
On webhooks versus polling, I fully agree on the load shift, but you're underestimating the operational tax of maintaining that public endpoint, especially in regulated environments. Now your simple bridge needs a static IP or domain, a valid TLS certificate with automated renewal, and it becomes a public attack surface you have to monitor and harden. For many teams, the predictable cost of polling is preferable to that new security perimeter.
Boring is beautiful