Sentry package v1.0.0

A Sentry authentication token for the customer's own organization, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'.

Issuance is external and two token kinds exist according to the reviewed authentication reference: an internal-integration token, created by an organization member from the org's developer settings (also available on self-hosted Sentry), and a user auth token, created by an individual user on the User settings > Personal Tokens page — prefer the internal-integration token for a service integration, because it authenticates as the integration rather than as a person.

Least privilege: assign only the scopes the registered capabilities need — project:read and org:read for the reads, event:read for the issue collection read, event:write or event:admin for issue update and issue deletion, and project:admin only where project deletion is enabled.

Expiry and revocation: internal-integration and user tokens do not expire on their own (only OAuth access tokens from the authorization-code flow carry the 30-day expiry described in the retrieved reference, and this pack does not register OAuth), so revocation is explicit deletion of the token in Sentry settings. The reviewed documentation does not establish whether disabling issuance, removing the integration's UI access, or deactivating the creating user invalidates tokens already issued, so the deployment must not rely on any of those mechanisms: each issued token must be deleted individually to guarantee revocation.

An expired or deleted value fails closed with a 401. Rotation therefore sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle of its own. Sentry also documents HTTP Basic auth with a legacy API key as username and an empty password, and DSN-based auth on a small number of endpoints; this pack registers the Bearer header only.

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.

The endpoint host 'sentry-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's Sentry host — sentry.io for the SaaS (Sentry's documented management-API authority; the regional *.ingest.sentry.io subdomains serve event ingestion only, not this API), or the customer's self-hosted Sentry hostname — before enabling, in every endpoint, in the resource locators and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. ORG, PROJECT and ISSUE_ID in the endpoint paths are placeholders the deployment binds to the concrete organization slug, project slug and issue id before enabling.

Every read endpoint here is a COLLECTION read: single-record reads (GET an issue, GET a project, GET an organization's details) are not registered.

Approval classification: the issue-update endpoint is judged by effect, not by its PATCH-like name. Per the retrieved Update an Issue reference — rechecked during the documented review against the single-issue operation, whose documented body parameters DO include merge and discard — the caller-controlled body can set status to resolved, ignored or resolvedInNextRelease (a workflow resolution — resolve equivalents sit at R3), can set merge=true (merging issues cannot be unmerged), can set discard=true (which discards the issues instead of updating them, a deletion of the issue and its future matching events), and can set isPublic=true (publishes the issue, and share is one of the designated actions requiring human approval because disclosed information cannot be made private again).

An unrestricted body therefore defeats any tier below R3, and the capability declares update, delete and share at the minimum R3 tier. Issue deletion and project deletion register as delete at the minimum R3 tier; according to the reviewed Delete a Project reference, project deletion is asynchronous — deletion is scheduled, not immediate, and once begun the project is hidden from most public views — so completion timing is not a guarantee of this registration, but the effect is deletion.

Documented exclusions — this pack does not register: the bulk issue-mutation endpoint (PUT /api/0/organizations/{org}/issues/, whose body applies the same merge/discard/resolve effects to many issues at once), event ingestion and the store/DSN endpoints (unmediated event submission), client key (DSN) management, team and organization member management, organization deletion, alert rules and notification settings, release and deploy creation (a deploy record notifies downstream integrations), issue comments and user feedback submission, and every other Sentry API.