canonical: https://jentic.com/apis/getping.info/getping # GETPing API Jentic publishes the only available OpenAPI specification for GETPing API, keeping it validated and agent-ready. GETPing is a lightweight uptime and ping-monitoring service that lets developers check whether a URL is reachable and track response times over a rolling history window. The API exposes eight endpoints covering single and batch pings plus monitor CRUD, designed for embedding in alerting agents, status dashboards, and incident-response playbooks. ## For AI agents Run on-demand pings, manage long-running URL monitors, and pull response-time history for status pages and uptime alerting workflows. ## Scope Does not handle log aggregation, application performance tracing, or transaction-level browser checks - use for URL ping and monitor history only. ## Capabilities - Run an on-demand ping against any HTTP URL and capture latency and status - Submit a batch ping job to test multiple URLs in a single request - Register a recurring monitor that polls a URL on a defined interval - Pull historical ping results for a monitor to compute uptime percentages - Update a monitor's URL or interval without losing its history - Remove a monitor when the underlying service is decommissioned ## Use cases ### Synthetic uptime monitoring for a SaaS GETPing acts as the synthetic-monitoring backbone for small teams that want pings from outside their infrastructure without standing up Prometheus or paying for a full APM suite. Register a monitor for each critical URL, then query the history endpoint from a dashboard or Slack bot to surface incidents within the polling interval. Example prompt: Create a monitor for https://api.example.com/health with a 60-second interval and post any failed checks to Slack #ops ### Pre-deploy reachability check CI pipelines call the on-demand ping endpoint after a deployment to confirm the new build's public URLs respond before flipping traffic. Batch ping covers multiple regional endpoints in a single call, keeping the pipeline step under a few seconds. Example prompt: Run a batch ping on the production, staging, and EU-region URLs and fail the deploy if any return a non-2xx status ### Incident response co-pilot An on-call agent receives an alert and asks Jentic 'is the payments API still down?' The agent routes the question to GETPing, runs an on-demand ping, and returns latency plus the last-hour history pulled from the monitor's records. This lets responders confirm or rule out an outage without opening another tab. Example prompt: Ping https://payments.example.com, fetch the last hour of monitor history, and summarise success rate and median latency ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/ping` | Ping a single URL on demand | | POST | `/ping` | Batch ping multiple URLs | | POST | `/monitors` | Create a recurring URL monitor | | GET | `/monitors` | List configured monitors | | GET | `/monitors/{monitorId}/history` | Retrieve monitor result history | | DELETE | `/monitors/{monitorId}` | Remove a monitor | ## Key resources - **Ping** — On-demand single-URL or batch reachability and latency checks - **Monitors** — Long-running scheduled checks with CRUD and history retrieval ## Why Jentic - **Setup:** Wiring GETPing by hand means setting its X-API-Key header, shaping ping and monitor payloads, and threading the monitor id through the history and delete paths yourself. Through Jentic you install once, import the GETPing API from the API Directory, store the key once, and your agent calls it. - **Permission scoping:** GETPing puts the monitor id in the URL path (`/monitors/{monitorId}/history`), so a rule can pin your agent to one monitor: it reads that monitor's history and status and nothing else. You choose the operations it may call, so deleting a monitor is not included unless you add it. - **Credential handling:** Your GETPing API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'check if a URL is up' or 'read a monitor's history', and Jentic returns the matching GETPing operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **UptimeRobot API** — Established uptime monitor with public status pages and a wider notifier integration set - **Pingdom API** — Enterprise synthetic monitoring with global probe locations and transaction checks - **StatusCake API** — SSL, domain, and uptime monitoring suite with team-friendly pricing ## FAQ ### Why is there no official OpenAPI spec for GETPing API? GETPing does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call GETPing 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 GETPing API use? GETPing uses an API key sent as the X-API-Key header. Through Jentic the key is stored encrypted in the vault and injected per request, so the raw key never lands in your agent's prompt or logs. ### Can I batch ping multiple URLs in one call? Yes. POST /ping accepts an array of URLs and returns one result per target, which is useful for regional reachability checks or pre-deploy smoke tests against a list of endpoints. ### What are the rate limits for the GETPing API? The OpenAPI spec does not declare specific rate limits. Treat it as a polite-use API: avoid sub-second polling intervals on monitors and prefer the monitor history endpoint over repeatedly hitting GET /ping for the same URL. ### How do I retrieve monitor history through Jentic? Search Jentic for 'get monitor history', load the GET `/monitors/{monitorId}/history` schema, then execute with your monitor identifier. The response gives you the time series you can chart on a status page. ### Can I update a monitor's URL without losing history? Yes. PUT `/monitors/{monitorId}` updates the monitor in place - its identifier and accumulated history are preserved while the polled URL or interval changes. ### Can I limit what my agent is allowed to do with the GETPing API? Yes. Because you run Jentic One yourself, your own rules decide which GETPing operations and credentials the agent may use. GETPing puts the monitor id in the URL path, such as GET `/monitors/{monitorId}/history`, so a rule can pin the agent to a single monitor and let it read only that monitor's history and status. You choose the operations it may call, so destructive actions like DELETE `/monitors/{monitorId}` stay off limits unless you explicitly add them.