canonical: https://jentic.com/apis/opsgenie.com/opsgenie

# Opsgenie Alert API

Jentic publishes the only available OpenAPI specification for Opsgenie Alert API, keeping it validated and agent-ready. Opsgenie is Atlassian's alerting and on-call management platform used by SRE and DevOps teams to route incidents to the right responders. The Alert API exposes endpoints to create, list, count, acknowledge, snooze, close, escalate, and tag alerts, plus add notes, assign responders, and trigger custom actions. Asynchronous operations return a request ID that can be polled via the request status endpoint. Authentication uses a Genie key passed in the Authorization header.

## For AI agents

Create, route, acknowledge, snooze, close, and escalate Opsgenie alerts across 18 endpoints, with API key authentication and async request tracking.

## Scope

Does not handle on-call schedule editing, incident timelines, or postmortem documents - use for Opsgenie alert creation, lifecycle, and routing actions only.

## Capabilities

- Create an alert with priority, message, responders, and tags from a monitoring source
- Acknowledge or close alerts to mark them as handled by the on-call responder
- Snooze a noisy alert so it does not page again before a chosen time
- Assign an alert to a specific responder or escalate it to the next on-call
- Add notes, tags, or custom actions to an alert during incident response
- Count alerts matching a filter for dashboards and reporting

## Use cases

### Routing monitoring alerts into on-call

When a monitoring system detects an outage, an automation agent calls POST /alerts with priority, message, responders, and tags so Opsgenie can fan the alert out to the right on-call schedule. Because alert creation is asynchronous, the agent retrieves the requestId from the response and polls GET `/alerts/requests/{requestId}` to confirm the alert was processed before moving on.

Example prompt: POST /alerts with priority=P1, message='Database master down', tags=['production','postgres'], then poll `/alerts/requests/{requestId}` until status is processed.

### Auto-acknowledge from chat or ticket

Incident commanders running ChatOps can acknowledge an alert directly from a chat command by calling POST `/alerts/{identifier}/acknowledge.` The same flow extends to ticket systems where opening a Jira issue marks the originating Opsgenie alert as acknowledged so it stops paging the rotation.

Example prompt: POST `/alerts/{identifier}/acknowledge` with note='picked up by Sam in #incidents' to silence the page.

### Suppressing flapping alerts

When a known-flaky service is generating repeated alerts, the on-call agent can call POST `/alerts/{identifier}/snooze` with an end time several hours out so the alert does not re-page during the silence window. The snooze record is visible to the rest of the rotation, which keeps the action transparent rather than hidden in a chat thread.

Example prompt: POST `/alerts/{identifier}/snooze` with endTime set 4 hours in the future and a note explaining why the alert is being suppressed.

### Escalation policies and assignment

When an alert sits unacknowledged past a threshold, an automation agent can use POST `/alerts/{identifier}/escalate` to move it to the next escalation level, or POST `/alerts/{identifier}/assign` to assign it to a specific responder. This is well suited to deadline-aware bots that watch alert age and bump them when they go stale.

Example prompt: Read alerts via GET /alerts, identify any open longer than 30 minutes, and POST `/alerts/{identifier}/escalate` to move them up a level.

### AI agent for incident triage

Through Jentic, an SRE assistant agent can answer 'what's open right now' by calling GET /alerts with a status=open filter, then offering to acknowledge or snooze specific alerts via the same toolset. The Opsgenie API key sits in your Jentic One instance, so triage agents can run alongside existing PagerDuty or chat integrations without exposing it.

Example prompt: Search Jentic for 'list open opsgenie alerts', execute GET /alerts with status=open, and propose an action (ack, snooze, escalate) for each.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/alerts` | Create an alert |
| GET | `/alerts` | List alerts |
| POST | `/alerts/{identifier}/acknowledge` | Acknowledge an alert |
| POST | `/alerts/{identifier}/close` | Close an alert |
| POST | `/alerts/{identifier}/snooze` | Snooze an alert |
| POST | `/alerts/{identifier}/escalate` | Escalate an alert |
| GET | `/alerts/requests/{requestId}` | Get the status of an async alert request |

## Key resources

- **Alerts** — Create, list, count, get, and delete alerts
- **Alert Actions** — Acknowledge, close, snooze, escalate, and execute custom actions
- **Notes & Tags** — Annotate alerts with notes and add or remove tags
- **Responders & Teams** — Assign responders, add teams, and route alerts
- **Requests** — Track the status of asynchronous alert operations

## Why Jentic

- **Setup:** Wiring the Opsgenie Alert API by hand means prefixing your key with 'GenieKey ' in the Authorization header, choosing the US or EU region host, and polling the async request endpoint to confirm an alert action landed. Through Jentic you install once, import the Opsgenie Alert API from the API Directory, store the key once, and your agent calls it while the GenieKey prefix and region host are handled for you.
- **Permission scoping:** Opsgenie puts the alert identifier in the URL path (`/alerts/{identifier}/...`), so a rule can pin your agent to acting on one alert. You choose the operations it may call, so actions like closing or escalating an alert are not included unless you add them alongside acknowledge or snooze.
- **Credential handling:** Your Opsgenie GenieKey is stored once, encrypted, by your own Jentic One instance and injected as the Authorization header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an opsgenie alert' or 'acknowledge an alert', and Jentic returns the matching operation under /alerts with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **PagerDuty** — Incident response platform with on-call schedules and automation
- **Atlassian Jira** — Issue tracker commonly paired with Opsgenie for postmortems and tickets
- **New Relic** — Observability platform that emits events Opsgenie turns into pages

## FAQ

### Why is there no official OpenAPI spec for Opsgenie Alert API?

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

Opsgenie uses an API key sent in the Authorization header in the format 'GenieKey {apiKey}'. Through Jentic the GenieKey is stored encrypted in the vault and prefixed correctly at execution, so the agent never sees or assembles the header itself.

### Can I create an alert and add a note in a single call with this API?

Not in one call. POST /alerts creates the alert and POST `/alerts/{identifier}/notes` adds a note. Because alert creation is asynchronous, the agent waits for `/alerts/requests/{requestId}` to return the alert identifier before adding the note.

### What are the rate limits for the Opsgenie Alert API?

Opsgenie applies per-customer and per-endpoint quotas; create-alert is the most heavily limited operation. Treat 429 responses as a signal to back off and keep an eye on the X-RateLimit headers Opsgenie returns alongside responses.

### How do I acknowledge an alert through Jentic?

Search Jentic for 'acknowledge an opsgenie alert', load POST `/alerts/{identifier}/acknowledge`, and execute it with the alert ID. The vaulted GenieKey is supplied automatically and the response includes a request ID you can poll for confirmation.

### Why does creating an alert return a request ID instead of the alert?

Alert creation is asynchronous in Opsgenie. POST /alerts returns a requestId and the alert is created shortly after; agents call GET `/alerts/requests/{requestId}` to retrieve the eventual alert ID and confirm successful processing.

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

Yes. Jentic One is self-hosted, so your own rules decide which Opsgenie operations and which GenieKey the agent may use. Because the alert identifier sits in the URL path (`/alerts/{identifier}/...`), a rule can pin the agent to acting on a single alert, and you choose which operations it can call. That means you can allow lighter actions like POST `/alerts/{identifier}/acknowledge` or /snooze while withholding /close or /escalate until you add them.
