Instatus API

Name: Instatus API
Brand: Instatus API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilitybearer14 EndpointsREST

For Agents

Manage Instatus status pages, components, and incidents — create pages, update component health, and post incident updates programmatically.

Install Jentic One Beta

Connect the Instatus API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Instatus 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://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# 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 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 Instatus API.

List and update status pages via /v2/pages and /v2/{page_id}

Read and update individual components on a page via /v2/{page_id}/components/{component_id}

Create new components on a page via POST /v1/{page_id}/components

GET STARTED

Start building with Instatus API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI specification for Instatus API, keeping it validated and agent-ready. The Instatus API lets engineering teams manage public and private status pages — pages, components, and incidents — programmatically across 14 endpoints. Most operations live under /v2, with a few /v1 create endpoints retained for compatibility, so an automation can create a page, attach service components, and post incidents from CI/CD or monitoring tooling. Authentication uses a bearer token issued from the Instatus dashboard.

Use Cases

Patterns agents use Instatus API for, with concrete tasks.

★ Auto-Post Incidents from Monitoring

When the monitoring system fires a critical alert, post a corresponding incident on Instatus so subscribers see the outage immediately. The integration uses the page id and component id from a config file, posts an incident with affected component and impact level, and follows up with status updates as the incident progresses.

When alert fires, POST a new incident on the configured page with the impacted component id and an initial 'investigating' status.

Component Health Sync from Health Checks

Mirror component health from an internal monitor into Instatus by calling PUT /v2/{page_id}/components/{component_id} whenever a check transitions between operational, degraded, and major outage. The status page reflects current state without an operator having to flip the component manually, and the small endpoint count makes this integration tractable in a few hours.

On health-check transition, PUT /v2/{page_id}/components/{component_id} with the new component status.

Multi-Page Provisioning for New Services

When a new internal service launches, create a dedicated Instatus page with POST /v1/pages, attach the relevant components via POST /v1/{page_id}/components, and store the resulting ids in service metadata. The provisioning step makes a status page available the day a service goes live without manual setup.

POST /v1/pages with the service name, then POST /v1/{page_id}/components for each tracked component.

AI Agent Incident Operator via Jentic

An on-call AI agent given access to Instatus through Jentic can open and update incidents in plain language. Jentic exposes each Instatus operation by intent and isolates the bearer token in its vault, so the agent posts updates without ever holding the credential.

Through Jentic, call instatus_create_incident with the page id, affected component id, and an initial 'investigating' message; follow up with instatus_update_incident as new information arrives.

Key Endpoints

14 endpoints — jentic publishes the only available openapi specification for instatus api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/v2/pages

List status pages

POST

/v1/pages

Create a status page

PUT

/v2/{page_id}

Update a status page

DELETE

/v2/{page_id}

Delete a status page

GET

/v2/{page_id}/components

List components on a page

PUT

/v2/{page_id}/components/{component_id}

Update a component status

GET

/v2/pages

List status pages

POST

/v1/pages

Create a status page

PUT

/v2/{page_id}

Update a status page

DELETE

/v2/{page_id}

Delete a status page

GET

/v2/{page_id}/components

List components on a page

PUT

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Instatus bearer tokens are stored encrypted in the Jentic vault and injected into the Authorization header at execution time. Agents never hold the raw token.

Intent-based discovery

Agents search Jentic by intent (for example 'post an Instatus incident' or 'update a component status') and Jentic returns the matching operation with its input schema.

Time to first call

Direct integration: about a day to wire bearer auth, page and component CRUD, and incident posting. Through Jentic: under 30 minutes — search, load, execute.

FAQs

Specific to using Instatus API through Jentic.

Why is there no official OpenAPI spec for Instatus API?

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

The Instatus API uses bearer authentication. You issue a token from the Instatus dashboard and send it as Authorization: Bearer <token>. Through Jentic, the bearer token is held in the encrypted Jentic vault and injected into the request at execution time.

Can I post incidents and update components with the API?

Yes. The spec includes endpoints under /v2/{page_id}/components/{component_id} for component status changes, and incident endpoints for posting and updating incidents. An automation can drive the full incident lifecycle from monitoring alerts.

What are the rate limits for the Instatus API?

The OpenAPI specification does not encode explicit rate limits. Status-page operations are typically low-frequency, so design integrations around event-driven calls rather than polling, and back off on 429 responses if they occur during incident bursts.

How do I open an incident through Jentic?

Run pip install jentic, then have the agent issue the search-load-execute flow with the query 'post an Instatus incident'. Jentic returns the matching operation; the agent supplies the page id, affected component id, status, and message, and gets back the created incident id.

Are page creation endpoints on /v1 or /v2?

Creation of pages and components in this spec sits on /v1 (POST /v1/pages and POST /v1/{page_id}/components), while reads, updates, and deletes use /v2. Use both prefixes side by side based on the operation.

Instatus API

Connect the Instatus API to your agent

Capabilities

Start building with Instatus API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs