canonical: https://jentic.com/apis/ping.ie/ping-ie # Ping.ie Network Diagnostics API Jentic publishes the only available OpenAPI specification for Ping.ie Network Diagnostics API, keeping it validated and agent-ready. Ping.ie is a comprehensive network diagnostic and monitoring service that provides developers with tools to test connectivity, measure latency, check DNS resolution, and monitor endpoint availability from multiple geographic locations. The API exposes twelve endpoints covering ping tests, traceroute operations, DNS lookups, port scanning, SSL certificate validation, and continuous uptime monitoring, designed for embedding in DevOps workflows, incident response systems, and infrastructure health dashboards. ## For AI agents Execute network diagnostics including ping tests, traceroutes, DNS lookups, port checks, and SSL validation, plus manage uptime monitors for continuous availability tracking. ## Scope Does not handle application performance monitoring, log aggregation, infrastructure metrics, or full synthetic browser testing - use for network-layer diagnostics and endpoint uptime monitoring only. ## Capabilities - Execute ICMP ping tests against any IP address or hostname with configurable packet count and timeout - Run traceroute operations to map network paths and identify routing bottlenecks between locations - Perform DNS lookups supporting A, AAAA, MX, TXT, CNAME, and NS record queries - Check TCP/UDP port availability and measure connection latency for specific services - Validate SSL/TLS certificates including expiration dates, chain integrity, and cipher suites - Create and manage uptime monitors with configurable check intervals from multiple probe locations - Retrieve historical monitoring data with downtime incidents and response time metrics ## Use cases ### Multi-region latency testing for CDN selection Ping.ie enables DevOps teams to measure response times from multiple geographic probe locations before selecting CDN endpoints or regional server deployments. Run concurrent ping tests from Europe, North America, and Asia-Pacific nodes, then analyze the latency distribution to determine optimal content delivery points. The API returns per-location metrics in a single response, eliminating the need to maintain distributed testing infrastructure. Example prompt: Ping example.com from Dublin, New York, and Singapore locations and return the average latency for each region ### Automated SSL certificate expiration monitoring Security teams integrate Ping.ie into compliance dashboards to track SSL certificate expiration across their domain portfolio. The API checks certificate validity, chain completeness, and expiration dates for any HTTPS endpoint, then surfaces certificates expiring within 30 days. Combine with the monitor endpoints to receive automated alerts when certificates need renewal, preventing unexpected expiration incidents. Example prompt: Check the SSL certificate for https://secure.example.com and alert if it expires within 30 days ### Incident response network diagnostics On-call engineers invoke Ping.ie during incident response to quickly diagnose connectivity issues without switching tools. An AI agent receives a report that 'users in Europe cannot reach the API,' then executes ping tests, traceroutes, and DNS lookups from European probe locations to determine whether the issue is DNS propagation, routing, or server availability. The structured API response feeds directly into incident timeline documentation. Example prompt: Run a traceroute from Dublin to api.example.com, check DNS resolution, and ping the resolved IP to diagnose a reported European connectivity issue ### Continuous uptime monitoring for SLA tracking Product teams use Ping.ie monitors to track availability against service-level agreements and display uptime percentages on public status pages. Create monitors for critical endpoints with 60-second check intervals, then query the history API to compute hourly, daily, and monthly uptime metrics. The API includes downtime incident details showing exact timestamps and failure reasons, supporting root-cause analysis and SLA reporting. Example prompt: Create a monitor for https://api.example.com/health checking every 60 seconds, then retrieve the last 30 days of uptime data for SLA reporting ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/ping` | Execute a ping test against a target host from specified locations | | POST | `/traceroute` | Run a traceroute to map the network path to a destination | | POST | `/dns/lookup` | Query DNS records for a domain with specified record type | | POST | `/port/check` | Check if a TCP or UDP port is open and measure connection time | | GET | `/ssl/validate` | Validate SSL certificate for an HTTPS endpoint | | POST | `/monitors` | Create a new uptime monitor with configurable interval and locations | | GET | `/monitors` | List all configured uptime monitors | | GET | `/monitors/{monitorId}` | Retrieve details for a specific monitor | | PUT | `/monitors/{monitorId}` | Update monitor configuration preserving history | | DELETE | `/monitors/{monitorId}` | Remove a monitor and its historical data | | GET | `/monitors/{monitorId}/history` | Retrieve check results and downtime incidents for a monitor | | GET | `/locations` | List available probe locations for distributed testing | ## Key resources - **Ping Tests** — ICMP and TCP ping operations from single or multiple geographic locations - **Traceroute** — Network path tracing to identify routing hops and latency sources - **DNS Lookups** — Query DNS records including A, AAAA, MX, TXT, CNAME, and NS types - **Port Checks** — TCP/UDP port availability testing with connection timing - **SSL Validation** — Certificate expiration, chain integrity, and cipher suite inspection - **Uptime Monitors** — Scheduled endpoint checks with CRUD operations and historical data retrieval ## Why Jentic - **Setup:** Wiring the Ping.ie Network Diagnostics API by hand means setting up its X-API-Key header auth and coding each ping, traceroute, DNS lookup, SSL check, and monitor call yourself. Through Jentic you install once, import Ping.ie from the API Directory, store the API key once, and your agent calls it. - **Permission scoping:** Ping.ie puts the monitor id in the URL path (`/monitors/{monitorId}`), so a rule can pin your agent to one monitor: it can read that monitor and its history. You choose the operations it may call, so changing or deleting a monitor is not included unless you add it, and one-off diagnostics like ping or traceroute can be allowed on their own. - **Credential handling:** Your Ping.ie API key is stored once, encrypted, by your own Jentic One instance and injected as the X-API-Key header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'run a traceroute' or 'check an SSL certificate', and Jentic returns the matching Ping.ie operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **GETPing API** — Lightweight uptime and ping monitoring with simpler endpoint coverage - **Pingdom API** — Enterprise synthetic monitoring with transaction checks and global probes - **UptimeRobot API** — Uptime monitoring with public status pages and notification integrations ## FAQ ### Why is there no official OpenAPI spec for Ping.ie API? Ping.ie does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Ping.ie 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 Ping.ie API use? Ping.ie 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 run ping tests from multiple geographic locations? Yes. The POST /ping endpoint accepts a locations array parameter that lets you specify probe points such as Dublin, London, New York, Singapore, and others. The response includes per-location latency metrics in a single call. ### How do I check DNS propagation after updating records? Use POST `/dns/lookup` with the domain and record type (A, AAAA, MX, etc.). The API queries from multiple DNS resolvers and returns the results showing whether your changes have propagated globally. ### What SSL certificate details does the API return? GET `/ssl/validate` returns the certificate chain, issuer, subject, validity dates, signature algorithm, key size, supported cipher suites, and any chain validation errors. This covers everything needed for security audits and expiration monitoring. ### Can I update a monitor's check interval without losing history? Yes. PUT `/monitors/{monitorId}` updates the monitor configuration in place - its identifier and accumulated check history are preserved while you change the interval, target URL, or probe locations. ### Can I limit what my agent is allowed to do with the Ping.ie API? Yes. Because you run Jentic One yourself, your own rules decide which Ping.ie operations and credentials the agent may use. You can allow one-off diagnostics such as POST /ping or POST /traceroute on their own, and since the monitor id sits in the URL path (`/monitors/{monitorId}`), a rule can pin the agent to reading a single monitor and its history. Changing or deleting a monitor via PUT or DELETE stays out of reach unless you explicitly add it.