Services API

In AlertifyPro, a service is a monitored endpoint. The API uses the term "service" — this maps to what users call "monitors" in the dashboard.

Base path: /api/v1/services

All endpoints require a valid JWT Bearer token.

---

List services

GET /api/v1/services

Optional query params:

• ?org=<org-slug> — specify organization by slug if not resolved from JWT

curl http://localhost:3001/api/v1/services \
  -H "Authorization: Bearer <token>"

Response:

[
  {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "organization_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "name": "Production API",
    "description": "Main REST API",
    "environment": "production",
    "endpoint": "https://api.yourapp.com/health",
    "check_type": "HTTP",
    "check_interval_seconds": 60,
    "timeout_seconds": 10,
    "status": "GREEN",
    "tags": []
  }
]

---

Get a service

GET /api/v1/services/{id}

curl http://localhost:3001/api/v1/services/550e8400-e29b-41d4-a716-446655440000 \
  -H "Authorization: Bearer <token>"

---

Create a service

POST /api/v1/services
Content-Type: application/json

Required fields:

Field	Type	Description
name	string	Display name
endpoint	string	URL or host:port to check
check_type	string	Check protocol (see table below)

Optional fields:

Field	Type	Default	Description
organization_id	string	From JWT	Override org (if multiple)
description	string	—	Human-readable description
environment	string	—	e.g. production, staging
check_interval_seconds	int	60	How often to check (seconds)
timeout_seconds	int	10	Timeout per check (seconds)

Example:

curl -X POST http://localhost:3001/api/v1/services \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production API",
    "endpoint": "https://api.yourapp.com/health",
    "check_type": "HTTP",
    "check_interval_seconds": 60,
    "environment": "production"
  }'

Response: 201 Created with the full service object.

---

Supported check types

Check types are normalized to uppercase internally. Either case is accepted in requests.

check_type	Protocol	Endpoint format
HTTP / HTTPS	HTTP/HTTPS GET	https://example.com/health
TCP / TELNET	TCP connection	host:port
PING / ICMP	ICMP ping	hostname or IP
DNS	DNS resolution	hostname
WEBSOCKET / WS	WebSocket upgrade	wss://example.com/ws
SMTP	SMTP greeting (220)	smtp.example.com:587
IMAP	IMAP banner (* OK)	mail.example.com:993
FTP	FTP greeting (220)	ftp.example.com:21
SSH	SSH banner	server.example.com:22
REDIS	Redis PING → +PONG	redis.example.com:6379
MYSQL / MARIADB	TCP port check	db.example.com:3306
MONGODB / MONGO	TCP port check	mongo.example.com:27017
POSTGRES / POSTGRESQL	TCP port check	db.example.com:5432
GRPC	TCP port check	grpc.example.com:50051

---

Status values

Status	Meaning
GREEN	Check passed within normal response time
YELLOW	Check passed but response time > 1000ms (degraded)
RED	Check failed (connection refused, timeout, bad response)

---

Update a service

PUT /api/v1/services/{id}
Content-Type: application/json

{
  "name": "Production API v2",
  "endpoint": "https://api.yourapp.com/v2/health",
  "check_interval_seconds": 30,
  "timeout_seconds": 15
}

---

Delete a service

DELETE /api/v1/services/{id}

Returns 204 No Content on success.

---

Trigger an immediate check

POST /api/v1/services/{id}/check

Enqueues an immediate ad-hoc check for the service.

Response: 202 Accepted

{ "status": "check enqueued" }

---

Service sub-resources

Path	Description
GET /api/v1/services/{id}/metrics	Uptime and response time history
GET /api/v1/services/{id}/uptime	Uptime percentage for a period
GET /api/v1/services/{id}/checks	Raw check log