FLUX Monitoring API

Base URL and format

All version 1 endpoints use JSON and begin with the production base URL below. The public OpenAPI 3.1 document is the complete machine-readable contract.

Production base URLURL

https://monitoring.fluxcdn.cloud/api/v1

Authentication and scopes

Create a token from Dashboard → Settings → API. Give it only the scopes required by the integration and choose an appropriate expiry. Send the token in the Authorization header.

Scope	Allows
`account:read`	Read workspace usage and limits.
`monitors:read`	List and read monitored services.
`monitors:write`	Create, replace, and delete monitored services.
`incidents:read`	List and read incidents.

Authenticated requestcURL

curl --request GET \
  --url https://monitoring.fluxcdn.cloud/api/v1/account \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_TOKEN'

Available endpoints

Method	Path	Purpose	Scope
`GET`	`/account`	Read usage and limits	`account:read`
`GET`	`/monitors`	List monitors	`monitors:read`
`POST`	`/monitors`	Create a monitor	`monitors:write`
`GET`	`/monitors/{id}`	Read a monitor	`monitors:read`
`PUT`	`/monitors/{id}`	Replace monitor settings	`monitors:write`
`DELETE`	`/monitors/{id}`	Delete a monitor	`monitors:write`
`GET`	`/incidents`	List incidents	`incidents:read`
`GET`	`/incidents/{id}`	Read an incident	`incidents:read`

Pagination

List endpoints use cursor pagination. Send per_page between 1 and 100. When meta.next_cursor is present, pass it as cursor on the next request. Do not construct or modify cursor values.

Next pagecURL

curl --get \
  --url https://monitoring.fluxcdn.cloud/api/v1/monitors \
  --data-urlencode 'per_page=25' \
  --data-urlencode 'cursor=CURSOR_FROM_PREVIOUS_RESPONSE' \
  --header 'Authorization: Bearer YOUR_TOKEN'

Safe retries for write requests

POST, PUT, and DELETE requests require an Idempotency-Key header containing 8 to 100 letters, numbers, underscores, periods, colons, or hyphens. Generate a new key for each intended change. Reuse the same key only when retrying the exact same method, path, and body.

If the original request completed, the stored response may be replayed. Reusing a key with different content returns a conflict instead of performing an uncertain second change.

Write request headersHTTP

Authorization: Bearer YOUR_TOKEN
Accept: application/json
Content-Type: application/json
Idempotency-Key: deploy-2026-08-01-0001

Rate limits and errors

Successful responses include X-RateLimit-Limit and X-RateLimit-Remaining. A 429 response includes Retry-After in seconds. Wait for that period and retry with backoff rather than sending a burst of requests.

Errors return an error code and a human-readable message. Validation errors may also include field details. Treat 401 as an invalid or expired token, 403 as a missing scope, 404 as unavailable in the token workspace, 409 as an idempotency conflict, and 422 as invalid input.

Integration checklist

Keep tokens outside source code, browser JavaScript, tickets, and chat messages.
Use a separate token for each integration so it can be revoked independently.
Choose the narrowest scopes and a real expiry date.
Validate all response fields before using them and tolerate new optional fields.
Use HTTPS, reasonable timeouts, exponential backoff, and idempotency keys.
Revoke a token immediately if it may have been exposed.