Install Jentic One Beta

Connect the Hyperping API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Hyperping 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.

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%2Fhyperping.com%2Fhyperping" | sh

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%2Fhyperping.com%2Fhyperping" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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 Hyperping API.

Create HTTP, port, or ICMP monitors with check frequency, probe regions, expected status code, and a required keyword

Set up cron job healthchecks with a ping period or a cron expression and a grace period, and pause or resume them

Acknowledge, unacknowledge, escalate, or resolve detected outages, filtered by status or type

Open a manual incident with a severity that triggers an escalation policy

GET STARTED

Start building with Hyperping API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Hyperping API for, with concrete tasks.

★ On-call assistant through Jentic

A developer's on-call agent watches Hyperping for ongoing outages and handles the first steps: acknowledge so escalation notifications stop, then post a status page incident. Through Jentic it finds each operation by intent, the Hyperping key is injected by the developer's own Jentic One instance, and a rule can withhold monitor deletion and status page edits.

Call GET /v2/outages with status ongoing, POST /v2/outages/{uuid}/acknowledge for the newest one, then POST /v3/incidents with type incident, a title, and the affected status page in statuspages

Monitor setup for a new service

Add uptime coverage when a service ships. A monitor needs only a name and url, and can set protocol http, port, or icmp, the http_method, a check_frequency such as 30 or 60, probe regions such as london and frankfurt, an expected_status_code like 2xx, and a required_keyword the response must contain.

Call POST /v1/monitors with name 'Checkout API', url https://api.acme.com/health, check_frequency 60, regions ['london', 'frankfurt'], expected_status_code 2xx, and required_keyword ok

Cron job heartbeat monitoring

Catch a backup or batch job that silently stops running. A healthcheck takes a name, a grace period, and either a simple ping period or a cron expression with a timezone, and its response includes the ping URL the job calls when it finishes; pausing it during a migration stops alerts until it is resumed.

Call POST /v1/healthchecks with name 'Daily Backup Job', cron '0 2 * * *', timezone UTC, grace_period_value 30, and grace_period_type minutes, and return the pingUrl from the response

Monthly SLA reporting

Report uptime to customers or leadership without exporting from the dashboard. The per-monitor report call returns SLA, MTTR, and outage data, taking from and to dates in ISO 8601 and defaulting to the last 7 days when they are omitted.

Call GET /v2/reporting/monitor-reports/{uuid} for the checkout monitor with from 2026-10-01T00:00:00Z and to 2026-10-31T23:59:59Z, and report its SLA and MTTR

Key Endpoints

38 endpoints — the hyperping api manages uptime monitoring and public status pages for a hyperping project.

METHOD

PATH

DESCRIPTION

POST

/v1/monitors

Create a monitor

GET

/v2/outages

List detected outages

POST

/v2/outages/{uuid}/acknowledge

Acknowledge an outage

POST

/v2/outages/{uuid}/resolve

Resolve an outage

POST

/v3/incidents

Create a status page incident

POST

/v3/incidents/{uuid}/updates

Add an incident update

POST

/v1/maintenance-windows

Create a maintenance window

GET

/v2/reporting/monitor-reports/{uuid}

Get a monitor's SLA and MTTR report

POST

/v1/monitors

Create a monitor

GET

/v2/outages

List detected outages

POST

/v2/outages/{uuid}/acknowledge

Acknowledge an outage

POST

/v2/outages/{uuid}/resolve

Resolve an outage

POST

/v3/incidents

Create a status page incident

POST

/v3/incidents/{uuid}/updates

Add an incident update

POST

/v1/maintenance-windows

Create a maintenance window

GET

/v2/reporting/monitor-reports/{uuid}

Get a monitor's SLA and MTTR report

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring the Hyperping API by hand means creating a project API key, sending it as a bearer token, and keeping three API versions straight: monitors and healthchecks under /v1, outages and status pages under /v2, and status page incidents under /v3. Through Jentic you install once, import Hyperping from the API Directory, store the key once, and your agent calls it.

Permission scoping

Hyperping puts the monitor, outage, incident, and status page id in the URL path (/v1/monitors/{uuid}, /v2/outages/{uuid}/...), so a rule can pin your agent to one monitor or one status page. You choose the operations it may call, so destructive ones like deleting a monitor or a status page are not included unless you add them.

Credential isolation

Your Hyperping 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 'acknowledge an outage' or 'create an uptime monitor', and Jentic returns the matching Hyperping operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Hyperping API through Jentic.

What authentication does the Hyperping API use?

Per its OpenAPI spec, the Hyperping API uses a bearer token: an API key created on the project's developers page in the Hyperping app, sent in the Authorization header. Through Jentic the key is stored encrypted by your own Jentic One instance and injected per call.

What is the difference between outages and incidents in the Hyperping API?

Outages, under /v2/outages, are the alerting side: detected or manual incidents that you acknowledge, escalate, or resolve, and that can trigger an escalation policy. Incidents, under /v3/incidents, are what your status page shows: a title, a type of outage or incident, affected components, the status pages it appears on, and timeline updates.

How do I change the sections of a Hyperping status page?

PUT /v2/statuspages/{uuid} changes only the fields you send, except sections: when present, it replaces every section of the page. Start from GET /v2/statuspages/{uuid}, change what you need, and send all the sections back, or omit sections to leave them as they are.

What are the rate limits for the Hyperping API?

The OpenAPI spec does not specify rate limits. Check Hyperping's developer documentation at https://hyperping.com for current limits.

How do I acknowledge an outage with the Hyperping API through Jentic?

Search Jentic for 'acknowledge an outage' to get POST /v2/outages/{uuid}/acknowledge, find the outage id with GET /v2/outages filtered to status ongoing, and call it to stop further escalation notifications. To run it on your own infrastructure, install Jentic One from its GitHub repo and store your Hyperping key once.

Is there a Hyperping MCP server?

You don't need an MCP server to give your agent Hyperping. Jentic connects it directly from the API Directory: import it, store your API key once, and your agent calls the operations you allow, discovered on demand rather than loaded into its context.

Can I limit what my agent is allowed to do with the Hyperping API?

Yes. For example, write a rule that allows only GET /v2/outages, POST /v2/outages/{uuid}/acknowledge, and POST /v3/incidents/{uuid}/updates, so the agent can triage outages and post timeline updates but cannot delete monitors, edit status pages, or schedule maintenance. Your Jentic One instance logs the calls it makes.

Hyperping API

AI ReadinessAI-Aware (B)66/100

See full scorecard

Official vendor OpenAPI document · agent-readyDeveloper ToolsMonitoring Observabilitybearer38 EndpointsREST

For Agents

Create and tune Hyperping uptime monitors and cron healthchecks, acknowledge, escalate, or resolve outages, post status page incidents and updates, schedule maintenance windows, and pull SLA and MTTR reports.

Use for: Create an uptime monitor for https://acme.com checked from London and Frankfurt, Acknowledge the ongoing outage on the API monitor, Post an investigating update on the status page, Schedule a maintenance window for tonight's database upgrade

Not supported: Does not collect application logs, traces, or metrics, run synthetic browser journeys, or page people outside Hyperping escalation policies. Use for Hyperping uptime monitors, healthchecks, outages, status pages, and uptime reports only.

The Hyperping API manages uptime monitoring and public status pages for a Hyperping project. It creates and updates HTTP, port, and ICMP monitors with a check frequency, probe regions, expected status code, and required keyword, and it runs healthchecks that expect a ping from a cron job on a fixed period or a cron expression. When something breaks, it lists detected outages and lets you acknowledge, escalate, or resolve them, open manual incidents that trigger escalation policies, and post status page incidents with timeline updates. Maintenance windows suppress alerts for chosen monitors, and monitor reports return SLA, MTTR, and outage data for a date range.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: ASignals: 4

97%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

100%

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

60%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: B-Signals: 4

13%

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

30%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

100%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: D+Signals: 4

35%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

64%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: B-Signals: 1

60%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: A-Signals: 1

73%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the Hyperping API to your agent

Capabilities

Start building with Hyperping API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Hyperping API

Jentic AI Readiness Score

Hyperping API

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness