This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern
Before you enable this package
For existing Opsgenie customers only: new sales ended June 4, 2025, and Atlassian will shut down Opsgenie on April 5, 2027. Plan migration before that date; this package does not cover the replacement Jira Service Management APIs. The endpoint host 'opsgenie-api.invalid' is a reserved .invalid placeholder that fails closed until you substitute the real host in both the endpoint URLs and the egress allowlist.
Lifecycle source: Atlassian's Opsgenie migration notice, checked September 30, 2026. Existing REST APIs end April 5, 2027; test the migration destination separately.
Read each action's effects and exclusions below. Before installation, also read the complete package requirements, including credential issuance, scope, expiry, and provider permissions. These are deployment prerequisites, not capabilities this package supplies.
Capabilities (9)
Each capability below is one registered operation. The complete package JSON includes its exact network destination allowlist. The repository stores it at packs/opsgenie.json and embeds a copy in the release binary.
Risk tiers. R0 is the minimum for reads. R2 is the minimum for write, create, update, execute, and invoke. R3 is the minimum for delete, send, pay, deploy, approve, share, and transfer. Operators can raise these levels. A minimum tier does not measure the operation's business or confidentiality risk.
On supported execution paths routed through AAES Govern, the R3 actions listed below require approval by an authorized person. Bypass paths and observation-only registrations are outside that guarantee. A provider's restoration feature does not remove this approval requirement. A provider-side approval, such as approving a GitLab merge request, is also separate from AAES Govern human approval. The capability matrix shows which execution paths are implemented, restricted to lab use, or refused at startup. Live compatibility must be tested in your environment.
Field guide. Endpoint is the service address and request method. Connector is the adapter that makes the call. Custody describes how the credential is held; the credential reference identifies the value to resolve. Data class sets handling requirements: pii means personal data, financial means financial records, and internal means internal organizational data.
opsgenie.alerts.list v1.0.0R0
- Kind
- tool
- Action
- read
- Endpoint
GET https://opsgenie-api.invalid/v2/alerts- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
List alerts.
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.
opsgenie.alerts.count v1.0.0R0
- Kind
- tool
- Action
- read
- Endpoint
GET https://opsgenie-api.invalid/v2/alerts/count- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- internal
Count alerts.
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.
opsgenie.alerts.read v1.0.0R0
- Kind
- tool
- Action
- read
- Endpoint
GET https://opsgenie-api.invalid/v2/alerts/ALERT_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Read alerts.
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.
opsgenie.alerts.create v1.0.0R3
- Kind
- tool
- Actions
- create, send
- Endpoint
POST https://opsgenie-api.invalid/v2/alerts- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Create alerts.
Create an alert.
The 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.
The 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.
opsgenie.alerts.acknowledge v1.0.0R3
- Kind
- tool
- Actions
- update, send
- Endpoint
POST https://opsgenie-api.invalid/v2/alerts/ALERT_ID/acknowledge- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Acknowledge alerts.
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.
That 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.
opsgenie.alerts.close v1.0.0R3
- Kind
- tool
- Actions
- update, send
- Endpoint
POST https://opsgenie-api.invalid/v2/alerts/ALERT_ID/close- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Close alerts.
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.
That 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.
opsgenie.alerts.notes.add v1.0.0R3
- Kind
- tool
- Actions
- create, send
- Endpoint
POST https://opsgenie-api.invalid/v2/alerts/ALERT_ID/notes- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Add alert notes.
Add a note to an alert: a new note object comes into existence, so the declared actions 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).
Per 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.
The 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.
opsgenie.alerts.escalate v1.0.0R3
- Kind
- tool
- Actions
- update, send
- Endpoint
POST https://opsgenie-api.invalid/v2/alerts/ALERT_ID/escalate- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Escalate alerts.
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.
ALERT_ID is a placeholder the deployment binds to a concrete alert identifier before enabling.
opsgenie.alerts.delete v1.0.0R3
- Kind
- tool
- Action
- delete
- Endpoint
DELETE https://opsgenie-api.invalid/v2/alerts/ALERT_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-opsgenie-geniekey- Data class
- pii
Delete alerts.
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.
On supported execution paths mediated by AAES Govern, 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.
Credential reference
The credential field names a reference rather than containing credential material. Packs are designed not to contain secrets; the format checks cover only known credential formats and cannot prove that arbitrary text contains no secrets. Installing a package registers its capabilities. Configure the provider credentials, endpoints, and network access, then test the integration in your environment before enabling it.
- Reference
secret-ref-opsgenie-geniekey- Custody
- customer_vault
- Injection
- header (Authorization)
Configure the value and injection format specified in the package. Assign responsibility for credential rotation and revocation, restrict provider permissions, and keep credential material out of logs and responses.
Complete credential requirements
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.
Issuance, 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.
Because 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.
Prefer 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.
Executor 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.
Resources
opsgenie-alerts(api, pii):https://opsgenie-api.invalid/v2/alerts
Technical package and review record
Complete provider requirements and exclusions
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.
ALERT_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}.
A 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).
Approval 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.
Escalate is registered as update and send at the minimum R3 tier: it routes the alert to an escalation's recipients, which triggers their notifications.
Acknowledge 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.
Alert 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.
Documented 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.
These 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.
Download the complete package JSON for exact network allowlists, credential requirements, exclusions, and setup notes. Read these requirements before installation.
The full documentation review record is supplied in the evaluation package. The evaluation package runs in your environment and comes only with the paid design partnership. This page reproduces the source links and review block; the full record is available for evaluation. Discuss a design partnership to inspect it before installation.
Review block
This section reproduces the review block recorded in the pack file. The evidence and approval record is separate: for a reviewed pack, it is in the evaluation materials and in the release binary's embedded assets.
Review completed: 2026-09-22
2 sources, retrieved 2026-09-21
- https://docs.opsgenie.com/docs/alert-api (retrieved 2026-09-21)
- https://support.atlassian.com/opsgenie/docs/alert-notifications-flow/ (retrieved 2026-09-21)
Current documentation links are navigation aids. They do not change the package, its historical sources or its review date. Review dates describe a documentation review, not a live integration test. No package is provider-endorsed or yet tested against a live provider tenant.
Release identity
SHA-256 of the pack file bytes: dabe31dcf18160e6874794afa4e51dd6c3af0c54d945d2a90177b786357503fb
Distributable: yes, digest matches the release manifest. Editing a package changes its release identity. A deployment plan checks its own file digests; it does not restore reviewed status or authenticate approval.