GETPing API
★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring ObservabilityapiKey8 EndpointsREST
For Agents
Run on-demand pings, manage long-running URL monitors, and pull response-time history for status pages and uptime alerting workflows.
Use for: I need to check whether https://example.com is up right now, Set up a monitor that pings my staging server every 5 minutes, Retrieve the last 24 hours of ping history for monitor abc123, List all monitors I currently have configured
Not supported: Does not handle log aggregation, application performance tracing, or transaction-level browser checks - use for URL ping and monitor history only.
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.
Install Jentic One Beta
Connect the GETPing API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the GETPing API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgetping.info%2Fgetping" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgetping.info%2Fgetping" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with GETPing API.
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
Patterns agents use GETPing API for, with concrete tasks.
★ 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.
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.
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.
Ping https://payments.example.com, fetch the last hour of monitor history, and summarise success rate and median latency
Key Endpoints
8 endpoints — jentic publishes the only available openapi specification for getping api, keeping it validated and agent-ready.
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
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
Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using GETPing API through Jentic.
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.
GET STARTED