Bulk-Monitoring 25+ FiveM Servers With the CFXR API

For checking more than one server at a time, CFXR's bulk resolve endpoint — POST /api/resolve/bulk — accepts up to 25 join codes in a single request and returns each one's status in one response. For a one-off check the built-in bulk resolver page does this without any code; for anything recurring, calling the endpoint yourself is the way to build a lightweight monitoring dashboard.

The request is a plain POST with a JSON body containing an inputs array of join codes, for example curl -X POST https://cfxr.cc/api/resolve/bulk -H "Content-Type: application/json" -d '{"inputs": ["b578o4", "abcd12"]}'. Each entry in inputs can be a bare join code, a full cfx.re/join/ link, or any of the other formats the single resolve endpoint accepts — you don't need to normalize them yourself before sending. The response returns a result per input, in the same order, so you can match them back up against whatever list you're tracking.

The full field-level reference for what each server's result object contains — name, status, player count, endpoint and hosting data — is documented at the API reference, alongside the machine-readable OpenAPI 3.1 spec. For a dashboard, the fields that typically matter most are the online/offline status and player count for each server — the fields you'd check on a schedule to notice a server going down or filling up — with hosting and resource data being more useful for periodic auditing than for a minute-to-minute view.

The /bulk page is the fastest route for a one-off check — paste in a list of codes, get results, export as JSON or CSV, done. It's not built to run unattended, though, so if you want a dashboard that stays current on its own, calling /api/resolve/bulk from a scheduled job (a cron job, a serverless function on a timer, a small script on a VPS) and storing the results yourself is the more appropriate route. That gives you your own history over time, rather than a snapshot you'd otherwise have to re-run and re-export by hand. It also means you decide the polling interval and storage format rather than being limited to whatever a single export captures at the moment you ran it.

A simple, common pattern is a small script that calls the bulk endpoint once every few minutes, appends the results to a lightweight datastore, and feeds a dashboard or Discord channel from there. None of that requires anything beyond the plain HTTP call — there's no separate "monitoring API" distinct from the resolve endpoints themselves.

Bulk requests count toward the same rate limit as any other endpoint, reflected in the X-RateLimit-* response headers, with a 429 and a Retry-After header if you go over. Because a single bulk call already covers up to 25 servers, most dashboards stay comfortably under the unauthenticated limit even on a fairly tight polling schedule — but if you're running multiple dashboards, polling more than a handful of times a minute, or combining bulk calls with per-server history lookups, an API key from /account/api-keys gives you an elevated limit and is worth setting up before you start seeing 429 responses rather than after.