canonical: https://jentic.com/apis/api.bleemeo.com/bleemeo # Bleemeo API Jentic publishes the only available OpenAPI specification for Bleemeo API, keeping it validated and agent-ready. The Bleemeo API gives programmatic access to a SaaS monitoring platform that collects metrics, logs, and health checks from Linux, Windows, container, and Kubernetes agents. Through this API you can list and delete agents, query metrics and services, manage dashboards, and exchange JWT tokens for stateless calls. It is aimed at teams who already run the Bleemeo agent and want to wire monitoring data into incident workflows or internal tooling. ## For AI agents Query monitoring agents, metrics, services, and dashboards from a Bleemeo account, and exchange username and password for a JWT to authenticate stateless calls. ## Scope Does not handle agent installation, log ingestion, or alert routing configuration - use for querying monitored agents, metrics, services, and dashboards only. ## Capabilities - Authenticate with username and password to obtain a short-lived JWT for subsequent requests - List and inspect Bleemeo agents reporting from servers, containers, and Kubernetes nodes - Query collected metrics and service objects to investigate the health of monitored infrastructure - Create and update dashboards that group related metrics for a team or service - Delete agents that have been decommissioned to keep the monitored fleet inventory accurate ## Use cases ### Automated Agent Inventory Reconciliation Keep an accurate inventory of monitored hosts by reconciling Bleemeo agents against your CMDB or cloud provider inventory. The agent calls GET /agent/, compares the returned list with the source of truth, and issues DELETE `/agent/{id}`/ for any host that has been retired. This avoids paying for licences attached to dead servers and keeps alert noise down. Example prompt: Call GET /agent/ to list active agents, diff against an AWS EC2 inventory, and call DELETE `/agent/{id}`/ for each agent matching a terminated instance. ### Dashboard Provisioning for New Services Bootstrap a Bleemeo dashboard whenever a new service is deployed so engineers see metrics on day one. The agent posts to /dashboard/ with a name and a list of metrics, then assigns it to the relevant team. Pair this with your CI pipeline to make monitoring setup part of the service template rather than a manual onboarding task. Example prompt: Call POST /dashboard/ with name='checkout-service' and the metric IDs returned from a prior call to GET `/metric/.` ### Incident Triage with JWT-Authenticated Queries During an incident, an on-call agent calls POST /jwt-auth/ with operator credentials, then queries /metric/ and /service/ to pull recent values for the impacted host. The JWT keeps subsequent calls stateless and short-lived, which fits well with serverless on-call bots. The structured JSON response can be summarised back to the responder in chat. Example prompt: Call POST /jwt-auth/ to obtain a token, then GET /metric/ filtered by agent ID and post the latest 15-minute window of CPU and memory metrics to an incident channel. ### Agent-Driven Monitoring Lookups via Jentic Connect Bleemeo to an AI assistant through Jentic so an engineer can ask 'show me the health of host X' in chat. The assistant searches Jentic for the right Bleemeo operation, loads the input schema, and runs the call with credentials kept in your Jentic One instance. The Bleemeo username, password, and JWT never enter the model's context window. Example prompt: Use the Jentic Python SDK to search for 'list bleemeo agents', load the operation, and execute it to retrieve agents in the production account. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/jwt-auth/` | Obtain a JWT bearer token from username and password | | POST | `/jwt-refresh/` | Refresh an expiring JWT token | | GET | `/agent/` | List Bleemeo agents in the account | | GET | `/agent/{id}/` | Retrieve a single agent by ID | | DELETE | `/agent/{id}/` | Delete an agent that has been retired | | GET | `/metric/` | List metrics collected by agents | | GET | `/dashboard/` | List configured dashboards | | POST | `/dashboard/` | Create a new dashboard | ## Key resources - **Agents** — List, retrieve, and delete monitoring agents. - **Metrics** — Query metrics collected by Bleemeo agents. - **Services** — List monitored services discovered by agents. - **Dashboards** — List and create dashboards grouping metrics. - **Auth** — Exchange credentials for JWT and refresh tokens. ## Why Jentic - **Setup:** Wiring the Bleemeo API by hand means choosing between its basic and bearer auth, calling the jwt-auth and jwt-refresh routes, and mapping the agent, metric, and dashboard endpoints yourself. Through Jentic you install once, import Bleemeo from the API Directory, store the credential once, and your agent calls it. - **Permission scoping:** Bleemeo puts the agent id in the URL path (`/agent/{id}`/), so a rule can pin your agent to one monitored agent: it can read that agent's details and nothing else. You choose the operations it may call, so destructive ones like agent deletion are not included unless you add them. - **Credential handling:** Your Bleemeo username, password, and JWT tokens are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list monitoring agents' or 'create a dashboard', and Jentic returns the matching Bleemeo operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **New Relic** — Larger SaaS observability platform with APM, logs, and infrastructure monitoring under one API. - **Pingdom** — Synthetic uptime and page-speed checks that complement Bleemeo's host metrics. - **UptimeRobot** — Free-tier uptime monitoring for HTTP, ping, and port checks. ## FAQ ### Why is there no official OpenAPI spec for Bleemeo API? Bleemeo does not publish an OpenAPI specification on its docs site. Jentic generates and maintains this spec so that AI agents and developers can call Bleemeo API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Bleemeo API use? The API supports HTTP Basic Authentication with your Bleemeo username and password and JWT bearer tokens. The recommended pattern is to call POST /jwt-auth/ once with credentials, then send the returned JWT in the Authorization header on subsequent calls. Jentic stores the credentials encrypted and only scoped tokens reach the agent. ### Can I delete a retired agent through the Bleemeo API? Yes. Send DELETE `/agent/{id}`/ with the agent UUID and the agent will be removed from the account. Use GET /agent/ first to confirm the agent ID and that no metrics still depend on it before deletion. ### What are the rate limits for the Bleemeo API? Bleemeo does not publish a hard public quota; standard fair-use limits apply per account. JWT tokens expire on a short window so you should use POST /jwt-refresh/ to renew them rather than re-authenticating with the password on every call. ### How do I list metrics for a specific agent through Jentic? Search Jentic for 'list metrics' and the GET /metric/ Bleemeo operation is returned with its query schema. Load the operation, then execute it with the agent filter set to the target agent ID. The standard quickstart is pip install jentic, search, load, execute. ### Is the Bleemeo API free? Bleemeo offers a free tier with limited agent count and retention; full API access on production data requires a paid plan. The API itself is included with every paid plan with no extra per-call charge beyond the agent licence. ### Can I limit what my agent is allowed to do with the Bleemeo API? Yes. Because you run Jentic One yourself, your own rules decide which Bleemeo operations and credentials the agent may use. You can grant read-only calls like GET /agent/ and GET /metric/ while withholding destructive ones such as DELETE `/agent/{id}`/, and since the agent id sits in the URL path you can pin the agent to a single monitored agent so it only reads that agent's details. The operator picks each operation, so the agent calls only what you have explicitly allowed.