Integrations

This section is for third-party service providers integrating their products with Ionhour: incident-management vendors, status-page tooling, and managed service providers. If you are wiring your own application, monitoring platform, or CI pipeline into an Ionhour workspace, you are in the right place.

The Integration API is a token-protected REST surface at /api/v1. It reuses the same ionh_ API keys as the MCP integration but exposes a focused, curl-able set of endpoints built for machine-to-machine use.

Two directions

An integration usually spans both directions of the boundary:

• Inbound (you → Ionhour): call /api/v1 endpoints to declare and manage incidents, post status-page announcements, read authenticated status summaries, and announce deployments or maintenance windows.
• Outbound (Ionhour → you): register a Webhook alert channel to receive Ionhour's own incidents and alerts into your IMS as signed HTTP callbacks.

                 POST /api/v1/...  (Bearer ionh_…)
   Your system  ───────────────────────────────►  Ionhour
   (IMS, tooling)                                  (incidents, status pages)
                ◄───────────────────────────────
                 Webhook callback (X-IonHour-Signature)

Topics

Base URL

All Integration API endpoints live under the /api/v1 path:

https://api.ionhour.com/api/v1

Every request carries an ionh_ API key as a Bearer token. Start with Authentication, then confirm your key with the GET /v1/whoami smoke test.

Conventions

• Auth: Authorization: Bearer ionh_… on every /api/v1/* route.
• Pagination: list endpoints return a flat envelope — { items, total, page, itemCount, pageCount, limit }.
• Single resources: returned directly, with no wrapper object.
• Timestamps: ISO-8601, UTC.
• Errors: a stable envelope { statusCode, error, code, message } where code is a machine-matchable string. See the error-code table.