---
title: "Sentry connector"
description: "Connect Sentry to Overlane: Read Sentry issues, resolve them and delete them. Auth, setup, typed actions with their autonomy class, and events."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Sentry connector

{/* Generated from the connector's declaration and setup text by `pnpm --filter @overlane/sdk generate`. Do not edit. */}

Read Sentry issues, resolve them and delete them. The native path is Overlane observability and error evidence; this connects an existing Sentry organization.

Connectors are optional on every plan. The Overlane-native path is Overlane observability and error evidence; nothing in Overlane needs Sentry connected. Read [how connectors work](/developers/connectors/) first.

## Auth

OAuth. Scopes: `event:read`, `project:read`, `event:write`, `event:admin`.

## Set it up

1. Create an internal integration (or an OAuth application) in Sentry with the scopes listed above.
2. Copy its token and store it with the connect command below, choosing the region your organization uses.

```sh
overlane connector connect sentry --secret-env SENTRY_TOKEN --config region=us
overlane connector show sentry
```

Settings:

- `region`: us or de: the Sentry data region. These are the only two hosts the connector calls.

The credential is read from the environment variable (or standard input with `--secret-stdin`), stored in your team's encrypted vault and never shown again. Storing, rotating or revoking a credential is in the `secrets` [autonomy class](/developers/approval-rule/). Revoke it with `overlane connector revoke`, which deletes the stored secret.

## Actions

Run one with `overlane connector run`. The class says what the call needs from the autonomy gate; see [the approval rule](/developers/approval-rule/).

| Action | Kind | Autonomy class | What it does |
| --- | --- | --- | --- |
| `list_issues` | read | none | List a project's issues |
| `get_issue` | read | none | Read one issue |
| `get_issue_targets` | read | none | Resolve the latest event's stack frames to the files and lines to work on |
| `resolve_issue` | write | `issue_triage` | Mark an issue resolved |
| `delete_issue` | destructive | `deletion` | Delete an issue and its events |

```sh
overlane connector run sentry list_issues
```

## Events

Set the integration's webhook URL to `https://api.overlane.app/webhooks/connectors/<team>/sentry`, then store its client secret with `overlane connector connect sentry --webhook --secret-env SENTRY_CLIENT_SECRET --config region=us`.

| Event type | Meaning |
| --- | --- |
| `issue.created` | An issue was created |
| `issue.resolved` | An issue was resolved |
| `event_alert.triggered` | An alert rule fired |

Each event is verified against the stored webhook secret and kept once by the provider's event ID, so a replay changes nothing. List them with `overlane connector events`.

## Limits and content

Overlane makes at most 60 Sentry calls a minute for one team, to protect the provider's own quota. A call over it returns `429` with `Retry-After`. A rate limit from the provider itself is waited out with its `Retry-After` and retried.

Everything Sentry returns is data, labelled `untrusted_data`, never instructions. If the text looks like it is written to instruct an AI reader, the label says so and the text is returned unchanged; nothing in it changes what Overlane does.

## Sources

- [Sentry: integration platform webhooks](https://docs.sentry.io/organization/integrations/integration-platform/webhooks/)
- The connector follows the provider's documentation as of 2026-10-01.

Source: https://docs.overlane.app/developers/connectors/sentry/index.mdx