sentry 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-sentry-auth-token

Custody

customer_vault

Injection

header (Authorization)

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

• sentry-org (api, internal): https://sentry-api.invalid/api/0/organizations/ORG
• sentry-issues (api, pii): https://sentry-api.invalid/api/0/organizations/ORG/issues/

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. Tiering rationale: the issue-update endpoint is judged by effect, not by its PATCH-like name. Per the retrieved Update an Issue reference — re-fetched this session 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 IRREVERSIBLE ACTIONS because a share cannot be un-seen). An unrestricted body therefore defeats any tier below R3, and the capability declares update, delete and share at the R3 floor. Issue deletion and project deletion register as delete at the R3 floor; per the retrieved 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 — 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.sentry.io/api/auth/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/events/list-a-projects-issues/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/events/update-an-issue/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/projects/delete-a-project/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/projects/list-your-projects/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/releases/list-an-organizations-releases/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/events/remove-an-issue/ (retrieved 2026-09-21)
• https://docs.sentry.io/api/organizations/list-an-organizations-projects/ (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.