API documentation — UniMonitor

Authentication

Create a token under API tokens in your account, choose the permissions it needs, and send it as a bearer token. The token is shown once and stored hashed, so if you lose it, revoke it and make another.

curl https://www.unimonitor.unibagency.com/api/v1/me \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

Tokens are minted in the browser and never through the API. Creating a credential from an existing credential is how a read-only token becomes a write token.

Permissions

Each token carries an explicit list. A request to an endpoint the token was not granted answers 403 and names the permission it wanted, so you do not have to guess.

monitors:read: List monitors and read their current state.
monitors:write: Create, edit and delete monitors. Deleting one deletes its history.
incidents:read: List incidents, including the probe’s recorded cause.
incidents:manage: Post updates to an incident. These appear on your public status page.
metrics:read: Read uptime ratios and response times from the rollup tables.
status-pages:read: List status pages and the monitors published on them.

Endpoints

Identity

GET /api/v1/me Any token

The account this token belongs to, and what the token is allowed to do. The call to make first.

Monitors

GET /api/v1/monitors monitors:read

List your monitors. Filter with status and active.

GET /api/v1/monitors/{monitor} monitors:read

One monitor.

POST /api/v1/monitors monitors:write

Create a monitor. Validated exactly as the web form is, including the outbound-address checks.

PUT /api/v1/monitors/{monitor} monitors:write

Update a monitor. PATCH is accepted and behaves the same.

DELETE /api/v1/monitors/{monitor} monitors:write

Delete a monitor and its history. Answers 204.

Incidents

GET /api/v1/incidents incidents:read

List incidents. Filter with monitor_id, open and since.

GET /api/v1/incidents/{incident} incidents:read

One incident, with the public updates posted against it.

POST /api/v1/incidents/{incident}/updates incidents:manage

Post a public update. This text appears on your status page, so treat the permission accordingly.

Metrics

GET /api/v1/monitors/{monitor}/uptime metrics:read

Uptime for a monitor. Hourly buckets up to seven days, daily beyond. A bucket that measured nothing reports null rather than zero.

GET /api/v1/monitors/{monitor}/latency metrics:read

Response times in hourly buckets, up to seven days.

Status pages

GET /api/v1/status-pages status-pages:read

Your status pages and how many monitors each publishes.

GET /api/v1/status-pages/{statusPage} status-pages:read

One status page, with its components and their public names.

Pagination

Collections always answer with data and meta, even on a single page. Pass page and per_page; per_page is capped at 100.

{
  "data": [
    {
      "id": 12,
      "name": "Client homepage",
      "type": "http",
      "target": "https://example.cm",
      "status": "up",
      "interval_seconds": 60,
      "last_checked_at": "2026-09-04T08:41:00+00:00"
    }
  ],
  "meta": { "current_page": 1, "per_page": 25, "total": 1, "last_page": 1 }
}

Errors

Failures answer with an error object. The code is the stable part — branch on that rather than on the message, which changes when the wording improves or a French translation lands.

{
  "error": {
    "code": "missing_ability",
    "message": "This token does not have the monitors:write permission.",
    "required_ability": "monitors:write"
  }
}

401: No token, an unknown token, or one that has expired.
403: The token is valid but lacks the permission, or the account is suspended. The body says which.
404: No such record — including records that exist but belong to somebody else.
422: Validation failed. The standard errors object, keyed by field.
429: Rate limit reached. Per token, not per account.

Rate limits

Counted per token rather than per account, so one busy integration throttles only itself. The limit is 120 requests a minute.