opsgenie v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-opsgenie-geniekey

Custody

customer_vault

Injection

header (Authorization)

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>' — per the retrieved 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.

• opsgenie-alerts (api, pii): https://opsgenie-api.invalid/v2/alerts

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: per the retrieved 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). Tiering rationale: alert creation is registered as create AND send at the R3 floor: 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 un-sent — so send applies, and send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Escalate is registered as update AND send at the R3 floor: it routes the alert to an escalation's recipients, which triggers their notifications. Acknowledge and close are registered as update AND send at the R3 floor, and add-note as create AND send at the R3 floor: per the retrieved 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 IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer); 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 R3 floor: the retrieved reference establishes no restore path for a deleted alert, so this pack treats deletion as permanent, and delete is one of the IRREVERSIBLE ACTIONS. 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. That is a documented exclusion, not an approximated capability.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.opsgenie.com/docs/alert-api (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.