canonical: https://jentic.com/apis/hund.io/hund

# Hund API

Jentic publishes the only available OpenAPI specification for Hund API, keeping it validated and agent-ready. Hund is a hosted status page and incident-management platform; its API exposes 14 endpoints for managing components, component groups, issues, events, statuses, watchdogs, and metric providers that drive a live status page. Operators can open and update incidents, attach events to existing issues, configure watchdog probes, and post custom metric data programmatically. Authentication uses HTTP bearer tokens or HTTP basic credentials issued from the Hund dashboard.

## For AI agents

Open and update incidents, post events, manage components, and drive a Hund status page from an AI agent or automation pipeline.

## Scope

Does not handle on-call paging, log aggregation, or APM tracing - use for status-page incidents, components, and metric publishing only.

## Capabilities

- Open a new Hund issue with title, body, severity, and affected components
- Append events to an existing issue to track incident progress and resolution
- Add or remove components from a component group on a status page
- Configure watchdog monitors and preview their next scheduled check
- Post custom metric values to a metric provider for status page graphs
- Retrieve current status information for the configured Hund domain

## Use cases

### Automated Incident Reporting

Wire monitoring alerts from observability tools into Hund so that PagerDuty or Datadog incidents automatically open a public issue on the company status page. The /issues endpoint creates a new issue with affected components, severity, and a description, and the /events endpoint attaches subsequent updates as the incident progresses. Customers get visibility within seconds of detection.

Example prompt: POST to /issues with title='Payments degraded', severity='major', and affected_component_ids=['payments'] then attach an /events update.

### Component and Group Management

Programmatically maintain the structure of a status page as services come and go: add a new microservice as a component, attach it to a Production group, and remove deprecated components. This avoids drift between the service catalogue and the public status page when the engineering team ships fast.

Example prompt: Call POST `/groups/{group_id}/add_component` with the new payments-v2 component id.

### Custom Metric Reporting

Push application metrics like API latency, queue depth, or error rate into Hund metric providers so the status page graphs reflect live performance. The watchdog endpoint also lets operators preview the next probe to confirm a configuration before it ships. Together they keep status page data in sync with internal monitoring.

Example prompt: PATCH `/metric_providers/{metric_provider_id}` to publish a new latency reading of 123ms.

### AI Agent Incident Response

Give an on-call AI agent the ability to open and update Hund incidents directly. Through Jentic, the agent searches for 'open a status page incident', loads the input schema, and executes a POST to /issues with the right severity and components. Bearer credentials stay in your Jentic One instance rather than the agent context, which matters when the agent is exposed to user prompts.

Example prompt: Search Jentic for 'open a status page incident', load the Hund POST /issues schema, and execute with the affected components and severity.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/issues/{issue_id}` | Retrieve an issue by id |
| POST | `/events` | Append an event to an issue |
| POST | `/groups/{group_id}/add_component` | Add a component to a group |
| GET | `/statuses` | List configured statuses |
| PATCH | `/metric_providers/{metric_provider_id}` | Update a metric provider |
| GET | `/watchdogs/preview` | Preview the next watchdog check |
| GET | `/context` | Retrieve account and domain context |

## Key resources

- **Issues** — Create, retrieve, and update incidents on a status page
- **Events** — Append progress events to existing issues
- **Components** — Add components to and remove components from groups
- **Watchdogs** — Configure and preview watchdog monitors
- **Metric Providers** — Manage metric provider configuration and post readings
- **Statuses** — Read current status information for the configured domain

## Why Jentic

- **Setup:** Wiring the Hund API by hand means choosing between bearer and basic auth, targeting api.hund.io/v1, and shaping incident and metric payloads yourself. Through Jentic you install once, import the Hund API from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** This API puts resource ids in the URL path (`/issues/{issue_id}`, `/metric_providers/{metric_provider_id}`), so a rule can pin your agent to one issue or metric provider: it can read or update that resource and nothing else. You choose the operations it may call, so updating a metric provider is not included unless you add it.
- **Credential handling:** Your Hund bearer or basic credential 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 'open a status page incident' or 'read current statuses', and Jentic returns the matching Hund operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Atlassian Statuspage** — Statuspage is the Atlassian-owned alternative to Hund with deeper enterprise integrations and a larger feature surface
- **PagerDuty API** — PagerDuty handles on-call paging while Hund handles public status communication - they pair naturally
- **Opsgenie API** — Opsgenie alerts on-call responders and integrates with Hund for downstream public status communication

## FAQ

### Why is there no official OpenAPI spec for Hund API?

Hund does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Hund 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 Hund API use?

The Hund API supports both HTTP bearer tokens and HTTP basic authentication. Through Jentic the credentials are stored in the credential vault and injected at execution time, so the agent only sees a scoped reference rather than the raw token.

### Can I open an incident on the Hund status page through the API?

Yes. POST to /issues with a title, severity, and the affected component ids to open a new incident, then call POST /events to append progress updates as the situation changes. Both endpoints authenticate with the same bearer token.

### What are the rate limits for the Hund API?

The OpenAPI spec does not declare numeric rate limits. Check the Hund help docs at hund.io/help/api for current limits before scaling agent traffic, and watch for HTTP 429 responses to back off automatically.

### How do I add a component to a group through Jentic?

Search Jentic for 'add a component to a status page group', load the schema for POST `/groups/{group_id}/add_component`, and execute with the group id and component id. Install with pip install jentic and use the async search, load, and execute pattern.

### Can I push custom metrics to a Hund status page?

Yes. PATCH the `/metric_providers/{metric_provider_id}` endpoint with the new metric reading to update the graph displayed on the status page. This is suited to publishing application latency, queue depth, or error rates from observability pipelines.

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

Yes. Because you run Jentic One yourself, your own rules decide which Hund operations and credentials the agent may use, so you can grant it just POST /events to append incident updates while withholding the ability to open new issues or reconfigure watchdogs. Hund puts resource ids in the URL path, such as `/issues/{issue_id}` and `/metric_providers/{metric_provider_id}`, so a rule can pin the agent to a single issue or metric provider and let it read or update only that resource. Updating a metric provider is not included unless you add it.