Opsgenie-Compatible Alert API: Endpoints & Examples

Last updated Oct 31, 2026

Short answer

OpsPing accepts a documented subset of the Opsgenie Alert API v2 at https://api.opsping.com: create alerts with the Opsgenie JSON shape and alias deduplication, then acknowledge, unacknowledge, close, snooze, and add notes, tags, or details by alert ID or tiny ID. Authenticate with a new OpsPing API key using the familiar GenieKey header. Most senders change only the URL and key; the main gap is that actions by alias (identifierType=alias) are not supported, so tools that auto-resolve through the Opsgenie API should use OpsPing's native webhook integrations for resolution.

Base URL and authentication

	Opsgenie	OpsPing
Base URL	`https://api.opsgenie.com` or `https://api.eu.opsgenie.com`	`https://api.opsping.com` (or your private deployment's hostname)
Header	`Authorization: GenieKey <key>`	`Authorization: GenieKey <key>`, `Authorization: OpsPingKey <key>`, or `X-OpsPing-Key: <key>`
Key	Opsgenie integration or API key	A new OpsPing API key — `POST` requests need write scope
Create response	`202` with a `requestId` to poll	`202` with the `alertId` included

Supported endpoints

“Supported” means the path, method and core request shape match Opsgenie's Alert API v2. Response bodies are OpsPing's and are not guaranteed to be field-for-field identical to Opsgenie's.

Endpoint	Status	Notes
`POST /v2/alerts`	Supported	Opsgenie-shaped body (fields below); deduplicates on `alias`
`GET /v2/alerts`	OpsPing filters	`query`, `status`, `priority`, `source`, `limit`, `cursor`; other parameters return 400
`GET /v2/alerts/{id}`	Supported	By alert ID or numeric tiny ID
`GET /v2/alerts/count`	Supported
`DELETE /v2/alerts/{id}`	Supported	Needs a key with delete scope
`POST /v2/alerts/{id}/acknowledge`	Supported	Optional `user` is recorded as the actor
`POST /v2/alerts/{id}/unacknowledge`	Supported
`POST /v2/alerts/{id}/close`	Supported	By alert ID or tiny ID only — not by alias
`POST /v2/alerts/{id}/snooze`	Supported	`endTime` (ISO 8601)
`POST /v2/alerts/{id}/escalate`	Different behavior	Advances the alert's own OpsPing escalation policy; an `escalation` object in the body is ignored
`POST /v2/alerts/{id}/assign`	Different body	Takes `user` or `userId` (plus `note`); Opsgenie's `owner` object is rejected with 400
`POST / GET /v2/alerts/{id}/notes`	Supported
`POST /v2/alerts/{id}/tags`	Supported	Body `tags` array
`DELETE /v2/alerts/{id}/tags`	Different query	Removes one tag with `?tag=`; Opsgenie's comma-separated `?tags=` is not read
`POST /v2/alerts/{id}/details`	Supported	Adds custom details
`POST /v2/alerts/{id}/responders`	Different body	Takes a `responders` array of OpsPing references; Opsgenie's single `responder` object is not read
`GET /v2/alerts/{id}/logs`	Different path	Use `GET /v2/alerts/{id}/activities`
`POST /v2/alerts/{id}/attachments`	Different flow	Presigned upload (create, upload, complete); 10 MB, 10 per alert
`GET /v2/alerts/requests/{requestId}`	Not supported	Creation is synchronous; use the returned `alertId`
`?identifierType=alias / tiny`	Not supported	Action endpoints resolve alert ID or numeric tiny ID only
`POST /v2/heartbeats/{name}/ping`	POST only	Opsgenie also accepts GET, PUT, PATCH; switch to POST
`/v1/incidents, configuration APIs`	Not compatible	Incidents, schedules, teams and policies use OpsPing-native schemas

OpsPing also adds POST /v2/alerts/{id}/reopen and /unsnooze, which Opsgenie does not have. Every endpoint is documented in the API reference.

Fields accepted on `POST /v2/alerts`

Field	Rules in OpsPing
`message`	Required. 1–130 characters
`alias`	Up to 512 characters. Deduplication key: a new create with the alias of an open or acknowledged alert increments that alert's count instead of paging again
`description`	Up to 15,000 characters
`priority`	`P1`–`P5`; defaults to `P3`
`source`	Up to 100 characters
`entity`	Up to 512 characters
`tags`	Up to 20 strings, each up to 50 characters
`details`	Object of string values
`responders`	Up to 50. `user` by `id` or `username` (email); `team`, `schedule`, `escalation` by OpsPing `id`. Name-only references are rejected
`visibleTo`	`user` or `team` entries with an `id`
`actions`	Up to 10 strings, each up to 50 characters
`user`	Up to 100 characters; recorded as the actor
`note`	Up to 25,000 characters
`owner`	Must reference an OpsPing user in your tenant

OpsPing-only optional fields: serviceId (link the alert to an OpsPing service), runbookUrl, recurrenceKey, and skipEscalation. A request that breaks a limit — for example, 21 tags — is rejected with 400 and a message naming the field, rather than being truncated.

The “supported subset” caveat

No actions by alias. identifierType=alias and identifierType=tiny are not supported. Use the alertId returned on create, or the numeric tiny ID.
No request polling. GET /v2/alerts/requests/{requestId} does not exist; creation is processed synchronously.
Responders must exist in OpsPing. Teams, schedules and escalations are referenced by OpsPing ID; users by ID or email username.
Some action bodies differ. Assign takes user or userId instead of an owner object, escalate advances the alert's own escalation policy, adding responders takes a responders array, and tag removal takes a single ?tag=.
List queries are simpler. The Opsgenie query language is not implemented; unsupported query parameters return 400.
Configuration APIs differ. Schedules, teams, escalations and policies exist in OpsPing's API with their own schemas. Use the importer rather than replaying Opsgenie configuration calls.

Test every integration before cutover: send a firing and a resolution and confirm the result in OpsPing.

Examples

Prometheus Alertmanager (`opsgenie_configs`)

Change api_url and api_key. Keep the trailing slash: Alertmanager appends v2/alerts to api_url. Remove any responders that name Opsgenie teams by name, or replace them with OpsPing IDs.

# alertmanager.yml — before (Opsgenie)
receivers:
  - name: opsgenie
    opsgenie_configs:
      - api_url: https://api.opsgenie.com/
        api_key: <opsgenie-api-key>

# alertmanager.yml — after (OpsPing): only the URL and key change
receivers:
  - name: opsgenie
    opsgenie_configs:
      - api_url: https://api.opsping.com/
        api_key: <opsping-api-key>
        # OpsPing does not close alerts by alias, so resolved
        # notifications from this receiver are not applied.
        send_resolved: false

Alerts are created and deduplicated per alert group. Because Alertmanager resolves Opsgenie alerts with close by alias, use the native mapper when you want resolved notifications to close alerts:

# Auto-close on resolution: use OpsPing's native Alertmanager mapper
receivers:
  - name: opsping
    webhook_configs:
      - url: https://api.opsping.com/v2/webhooks/inbound/<integration-id>/<token>
        send_resolved: true

Full field mapping: Alertmanager integration.

Grafana (Opsgenie contact point)

In Alerting → Contact points, edit the Opsgenie contact point: set Alert API URL to https://api.opsping.com/v2/alerts, paste a new OpsPing key as the API key, and turn off Auto close incidents. Or provision it from a file:

# Grafana contact point provisioning (provisioning/alerting/*.yaml)
apiVersion: 1
contactPoints:
  - orgId: 1
    name: opsping-opsgenie-compatible
    receivers:
      - uid: opsping_genie
        type: opsgenie
        settings:
          apiUrl: https://api.opsping.com/v2/alerts   # was https://api.opsgenie.com/v2/alerts
          apiKey: <opsping-api-key>                   # new OpsPing key, not the Opsgenie key
          autoClose: false      # close by alias is not supported
          sendTagsAs: details   # keeps label sets within the 20-tag limit

Grafana can send every alert label as a tag; with sendTagsAs: tags or both, an alert with more than 20 labels, or a key:value label longer than 50 characters, is rejected by the tag limits, so details is the safer setting. For alerts that close on resolution, use a Grafana webhook contact point with OpsPing's Grafana integration instead.

Scripts and custom tools (curl)

curl -X POST https://api.opsping.com/v2/alerts \
  -H "Authorization: GenieKey $OPSPING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Disk usage above 90% on db-1",
    "alias": "db-1-disk-usage",
    "description": "/var/lib/postgresql at 91%",
    "priority": "P2",
    "source": "cron-check",
    "entity": "db-1",
    "tags": ["database", "disk"],
    "details": {"mount": "/var/lib/postgresql", "threshold": "90"}
  }'

# 202 Accepted — OpsPing returns the alert ID directly:
# {"result": "...", "alertId": "<id>", "requestId": "...", "took": 0}

# Acknowledge, add a note, then close — by alert ID (or numeric tiny ID)
curl -X POST https://api.opsping.com/v2/alerts/$ALERT_ID/acknowledge \
  -H "Authorization: GenieKey $OPSPING_API_KEY" \
  -H "Content-Type: application/json" -d '{"user": "deploy-bot"}'

curl -X POST https://api.opsping.com/v2/alerts/$ALERT_ID/notes \
  -H "Authorization: GenieKey $OPSPING_API_KEY" \
  -H "Content-Type: application/json" -d '{"note": "Rotated logs, usage at 70%"}'

curl -X POST https://api.opsping.com/v2/alerts/$ALERT_ID/close \
  -H "Authorization: GenieKey $OPSPING_API_KEY" \
  -H "Content-Type: application/json" -d '{"user": "deploy-bot"}'

Heartbeats

curl -X POST https://api.opsping.com/v2/heartbeats/nightly-backup/ping \
  -H "Authorization: GenieKey $OPSPING_API_KEY"

OpsPing answers with JSON, not Opsgenie's plain-text PONG, so update scripts that check the response body.

FAQ

Is OpsPing a drop-in replacement for the Opsgenie API?

For alert creation and the common actions by alert ID, mostly yes: the same v2 paths, the Opsgenie JSON shape, alias deduplication and the GenieKey header. It is not a full drop-in: actions by alias (identifierType=alias) are not supported, assign, escalate, add-responder and tag removal take different input, request-status polling is not available, and configuration APIs use OpsPing-native schemas.

Which header do I use?

Send an OpsPing API key as Authorization: GenieKey <key>, Authorization: OpsPingKey <key>, or X-OpsPing-Key: <key>. All three take the new OpsPing key; your Opsgenie key will not work.

Will Alertmanager and Grafana auto-resolve alerts through the Opsgenie-compatible endpoint?

No. Both resolve Opsgenie alerts by calling close with identifierType=alias, which OpsPing does not support. Alerts are created and deduplicated, but stay open until closed. For automatic resolution, use OpsPing's native Alertmanager or Grafana webhook integration, which closes alerts by fingerprint.

What happens to responders in my existing payloads?

Responders must resolve to objects in your OpsPing tenant: users by ID or email username, and teams, schedules and escalations by OpsPing ID. A payload that names a team only by its Opsgenie name is rejected, so remove those responders and route with OpsPing integrations and routing rules, or replace them with OpsPing IDs.

Is there an EU endpoint like api.eu.opsgenie.com?

Use https://api.opsping.com whether your Opsgenie account was in the US or EU region. Private single-tenant deployments use their own hostname.

Opsgenie® is a trademark of Atlassian. OpsPing is not affiliated with, sponsored, or endorsed by Atlassian.

Full API reference Step-by-step switch guide

OpsPing's Opsgenie-compatible alert API