{
  "schema": "aaes/capability-pack/1",
  "provider": "opsgenie",
  "version": "1.0.0",
  "description": "List, count, and read Opsgenie alerts; create, acknowledge, close, annotate, escalate, and delete alerts. Writes are asynchronous, and several actions can notify responders. Request-status polling is not registered.",
  "notes": "The endpoint host 'opsgenie-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the real Opsgenie API authority before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Per the retrieved Alert API reference the service authority is api.opsgenie.com, and customers on the EU instance use api.eu.opsgenie.com instead: substitute the authority that matches the customer's instance.\n\nALERT_ID in the endpoint paths is a placeholder the deployment binds to a concrete alert identifier before enabling; the reference also permits addressing an alert by alias or tiny-id via query parameters, and this pack registers the identifier path form only. ASYNC WRITES: according to the reviewed reference every alert write (create, delete, and every action POST) is processed asynchronously — the response is a 202 Accepted carrying a requestId, and the request's processing status is polled at GET /v2/alerts/requests/{requestId}.\n\nA 202 is therefore acceptance, not completion: this registration makes no claim that any write has taken effect when the call returns, and a caller that needs confirmation must poll the request-status endpoint (itself a read this pack does not register — see exclusions).\n\nApproval classification: alert creation is registered as create and send at the minimum R3 tier: the documented responders field on create routes the new alert to teams, users, escalations or schedules and triggers notification delivery to those recipients — a notification that cannot be recalled after delivery — so send applies, and send is one of the designated actions requiring human approval.\n\nEscalate is registered as update and send at the minimum R3 tier: it routes the alert to an escalation's recipients, which triggers their notifications.\n\nAcknowledge and close are registered as update and send at the minimum R3 tier, and add-note as create and send at the minimum R3 tier: according to the reviewed reference, acknowledgement, closure and added-note events can generate notifications to configured recipients — a conditional effect, not a guarantee that every call notifies, but one this registration cannot exclude — and send is one of the designated actions requiring human approval; a note is also visible to the alert's subscribers once added and the retrieved reference documents no per-note removal, so this registration makes no reversibility claim for it.\n\nAlert deletion is registered as delete at the minimum R3 tier: the retrieved reference establishes no restore path for a deleted alert, so this pack treats deletion as permanent, and delete is one of the designated actions requiring human approval.\n\nDocumented exclusions — this pack does not register: the request-status polling endpoint (GET /v2/alerts/requests/{requestId}); snooze, un-acknowledge, assign, add-team, add-responder, add-tags and remove-tags action endpoints; executing a custom action (POST /v2/alerts/{id}/actions/{action}) — a custom action can trigger an arbitrary integration workflow whose effect is not knowable from the retrieved reference, so it is excluded rather than approximated; alert property updates and details operations, note/log/recipient reads, attachment operations, and saved-search reads, creates, updates and deletes; and the separate integration, schedule, on-call, user, team, heartbeat and incident APIs, which the retrieved Alert API reference does not cover.\n\nThese are unregistered routes. Distinct from those, two caller-controlled parameter variants on registered routes are not excluded by the registration: saved-search selection via query parameters on the list endpoint, and alias/tiny-id addressing via the identifierType parameter on the get endpoint — both are intended restrictions only, and a deployment that needs them excluded must enforce that in adapter/query validation.",
  "credential": {
    "secret_ref_id": "secret-ref-opsgenie-geniekey",
    "custody": "customer_vault",
    "inject": "header",
    "inject_name": "Authorization",
    "note": "An Opsgenie API key for the customer's own account, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'GenieKey', one separating space, then the key — 'GenieKey <key>' — according to the reviewed Alert API reference. This pack selects customer_vault, with resolution and injection confined to the executor — the stored value is never exposed to the agent or written into prompts, plans or outputs.\n\nIssuance, rotation and revocation are external: the retrieved reference documents the header form but not key lifecycle operations, and this pack creates no key and the injector performs no lifecycle itself — it injects the stored value verbatim on every call.\n\nBecause lifecycle specifics (issuance authority, expiry behavior, revocation semantics) are not established by the retrieved reference, this pack claims none: issuance is an out-of-band deployment process that stores the value under this reference, and a key that is revoked outside the executor fails closed; note that rotation alone does not establish cut-off — replacing the stored value with a newly issued key stops the executor from using the old value, but whether the old key keeps working elsewhere depends on provider-side invalidation of it, which the retrieved reference does not document.\n\nPrefer a key whose access rights are limited to the alert operations this pack registers where the customer's key-management surface supports scoping; the retrieved reference does not document the scoping options, so least privilege is a deployment responsibility, not a property this pack asserts.\n\nExecutor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack."
  },
  "capabilities": [
    {
      "capability_id": "opsgenie.alerts.list",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "List alerts, including messages, owners, responders, and teams that can identify on-call people; classified as pii (personal data). Callers can narrow the collection or select a saved search using query parameters. This registration does not validate or strip those parameters. If saved-search selection must be excluded, enforce that boundary in the adapter's query validation.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.count",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "internal",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/count",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Count alerts matching an optional query. The response is an aggregate count, which discloses incident volume but no per-alert content, so the capability is classified as internal data.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Read one alert's message, description, owner, responders, and teams, including personal identifiers and caller-supplied text; classified as pii (personal data). Bind ALERT_ID before enabling. The caller can also set identifierType to address an alias or tiny-id on this same route. The pack does not validate or strip that parameter; enforce identifier-only access in adapter query validation if required.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.create",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "create",
        "send"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Create an alert.\n\nThe body is unrestricted: this registration does not restrict which fields a request may set, and the documented responders field routes the new alert to teams, users, escalations or schedules and triggers notification delivery to those recipients — a notification cannot be recalled after delivery, and send is one of the designated actions requiring human approval, so the capability is registered as create and send at the minimum R3 tier.\n\nThe body can name people as responders, so the capability is classified as pii (personal data). Per the retrieved reference the write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.acknowledge",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID/acknowledge",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "update",
        "send"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Acknowledge an alert: changes the alert's acknowledged state on record. The request carries an optional caller-supplied note and user attribution and the alert itself carries responder and owner identifiers, so the capability is classified as pii (personal data). Per the retrieved reference, acknowledgement and closure can generate notifications to configured recipients — a notification cannot be recalled after delivery, and send is one of the designated actions requiring human approval — so the capability is registered as update and send at the minimum R3 tier.\n\nThat is a conditional effect: not every call delivers a notification, but this registration cannot exclude it, so the tier must assume it. Per the retrieved reference the write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion. ALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.close",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID/close",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "update",
        "send"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Close an alert: changes the alert's open/closed state on record. The request carries an optional caller-supplied note and user attribution and the alert itself carries responder and owner identifiers, so the capability is classified as pii (personal data). Per the retrieved reference, acknowledgement and closure can generate notifications to configured recipients — a notification cannot be recalled after delivery, and send is one of the designated actions requiring human approval — so the capability is registered as update and send at the minimum R3 tier.\n\nThat is a conditional effect: not every call delivers a notification, but this registration cannot exclude it, so the tier must assume it. Per the retrieved reference the write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion. ALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.notes.add",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID/notes",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "create",
        "send"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Add a note to an alert: a new note object comes into existence, so the declared verbs are create and send. The note body is unrestricted caller-supplied free text attached to an alert that carries owner and responder identifiers, so the capability is classified as pii (personal data).\n\nPer the retrieved reference, added-note notifications to configured recipients can be generated — a notification cannot be recalled after delivery, and send is one of the designated actions requiring human approval — so the capability sits at the minimum R3 tier; that is a conditional effect, not a guarantee that every note notifies.\n\nThe retrieved reference documents no per-note removal through this endpoint, so this registration makes no reversibility claim. The write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion. ALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.escalate",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID/escalate",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "update",
        "send"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Escalate an alert to an escalation's recipients. The alert it routes carries owner and responder identifiers, so the capability is classified as pii (personal data). routing the alert to those recipients triggers their notifications, which cannot be recalled after delivery, so the capability declares update and send at the minimum R3 tier — send is one of the designated actions requiring human approval. Per the retrieved reference the write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion.\n\nALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "opsgenie.alerts.delete",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "opsgenie-api.invalid"
      ],
      "endpoint": "https://opsgenie-api.invalid/v2/alerts/ALERT_ID",
      "method": "DELETE",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-opsgenie-geniekey",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "delete"
      ],
      "resource_id": "opsgenie-alerts",
      "description": "Delete an alert: the target alert carries owner and responder identifiers and caller-supplied content, so the capability is classified as pii (personal data). The retrieved reference establishes no restore path for a deleted alert, so this pack treats deletion as permanent; delete is one of the designated actions requiring human approval.\n\nOn supported AAES-mediated execution paths, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths. The capability is registered at the minimum R3 tier. Per the retrieved reference the write is asynchronous: the response is a 202 Accepted with a requestId and acceptance is not completion. ALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.",
      "requires_review": true
    }
  ],
  "resources": [
    {
      "resource_id": "opsgenie-alerts",
      "kind": "api",
      "locator": "https://opsgenie-api.invalid/v2/alerts",
      "data_class": "pii",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    }
  ],
  "review": {
    "state": "library",
    "date": "2026-09-22",
    "sources": [
      "https://docs.opsgenie.com/docs/alert-api (retrieved 2026-09-21)",
      "https://support.atlassian.com/opsgenie/docs/alert-notifications-flow/ (retrieved 2026-09-21)"
    ],
    "reviewer_id": "aaes-eng"
  }
}