Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LENINMORENO13/OpsMind/llms.txt

Use this file to discover all available pages before exploring further.

The Update Monitor endpoint allows you to modify the name or url of an existing monitor identified by its numeric ID. Both fields are optional, making this a true partial-update (PATCH) operation — you can change just the name, just the URL, or both in a single request. Before applying changes, OpsMind validates the incoming URL against all other monitors to prevent duplicate entries, returning a clear 409 Conflict if a collision is detected.

​
Endpoint

PATCH /api/v1/monitors/:id
All requests must include a valid JWT in the Authorization header. The id path parameter must be a valid integer — non-numeric values are rejected with a 400 before any database query is executed.

​
Request

​
Headers

HeaderValueRequired
AuthorizationBearer <token>✅ Yes
Content-Typeapplication/json✅ Yes

​
Path Parameters

​
id
integer
required
The numeric ID of the monitor to update. This value must parse as a valid integer — strings such as "abc" or floating-point values will cause a 400 Invalid ID format response.

​
Body Parameters

Both fields are optional. Include only the ones you want to change.
​
name
string
A new human-readable label for the monitor. Updating the name also changes the lookup key used by GET /api/v1/monitors/status/:site.
​
url
string
A new URL to assign to the monitor. OpsMind checks this value against every other monitor in the system (excluding the current one). If another monitor already uses this URL, the request is rejected with 409 Conflict.

​
Curl Example

curl --request PATCH \
  --url https://your-opsmind-host/api/v1/monitors/3 \
  --header "Authorization: Bearer <your_jwt_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "payments-service-v2",
    "url": "https://api.payments.internal/v2/health"
  }'

​
Response

​
200 — Success

Returns a JSON envelope with the fully updated Monitor object inside data. 
{
  "success": true,
  "message": "Monitor updated successfully",
  "data": {
    "id": 3,
    "url": "https://api.payments.internal/v2/health",
    "name": "payments-service-v2",
    "isActive": true,
    "checkInterval": 300,
    "lastStatus": "UP",
    "createdAt": "2024-11-20T10:05:00.000Z",
    "updatedAt": "2024-11-21T09:00:00.000Z"
  }
}

​
Error Responses

​
400 — Invalid ID Format

Returned when the :id path parameter cannot be parsed as an integer. 
{
  "success": false,
  "error": "Invalid ID format"
}

​
500 — Monitor Not Found (Non-Existent ID)

The update controller does not perform an existence check before calling prisma.monitor.update. If no monitor exists for the given ID, Prisma throws a P2025 record-not-found error, which is caught by the generic error handler and returned as a 500 Internal Server Error. There is no clean 404 response for this case. 
{
  "success": false,
  "error": "Internal server error"
}
Unlike the delete endpoint, the update endpoint does not pre-check whether the monitor exists before attempting the write. If the ID is valid but refers to a monitor that does not exist, the response will be 500, not 404. Callers should use GET /api/v1/monitors to verify the ID before issuing an update.

​
409 — URL Already in Use

Returned when the new url value is already registered on a different monitor. The current monitor’s own URL is always excluded from the uniqueness check, so re-submitting the same URL as the current value will not trigger a conflict. 
{
  "success": false,
  "error": "Monitor with this URL already exists",
  "code": "URL_DUPLICATED"
}

​
401 — Unauthorized

Returned when the Authorization header is missing, malformed, or the token has expired. 
{
  "success": false,
  "error": "Unauthorized"
}

​
500 — Internal Server Error

Returned for unexpected database or application errors. 
{
  "success": false,
  "error": "Internal server error"
}

Build docs developers (and LLMs) love

Get started for freeTalk to us