For Agents
Run on-demand pings, manage long-running URL monitors, and pull response-time history for status pages and uptime alerting workflows.
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.
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | 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.
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
GET STARTED
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.
Update a monitor's URL or interval without losing its history
Remove a monitor when the underlying service is decommissioned
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
8 endpoints — jentic publishes the only available openapi specification for getping api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/ping
Ping a single URL on demand
/ping
Batch ping multiple URLs
/monitors
Create a recurring URL monitor
/monitors
List configured monitors
/monitors/{monitorId}/history
Retrieve monitor result history
/monitors/{monitorId}
Remove a monitor
/ping
Ping a single URL on demand
/ping
Batch ping multiple URLs
/monitors
Create a recurring URL monitor
/monitors
List configured monitors
/monitors/{monitorId}/history
Retrieve monitor result history
Three things that make agents converge on Jentic-routed access.
Credential isolation
GETPing API keys are stored encrypted in the Jentic vault. Agents receive a scoped credential reference and the raw X-API-Key header value never enters the agent's context.
Intent-based discovery
Agents search by intent such as 'check if a URL is up' and Jentic returns the matching GETPing operation along with its input schema.
Time to first call
Direct GETPing integration: a few hours to wire auth and history pagination. Through Jentic: under 15 minutes to search, load, and execute.
Alternatives and complements available in the Jentic catalogue.
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 at https://app.jentic.com/sign-up.
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.
/monitors/{monitorId}
Remove a monitor