> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sentry setup

ConfigView reads your Sentry organization through Sentry's API, using the token of an **internal integration** you create for ConfigView. An internal integration belongs to the organization, not to a person, so it keeps working when whoever set it up leaves.

You will end up with **2 secrets** in ConfigView (`SENTRY_AUTH_TOKEN`, `SENTRY_ORG_SLUG`), plus a third (`SENTRY_BASE_URL`) if your organization's data is stored in the EU or you run Sentry yourself.

> **Scope of this integration today.** ConfigView reads who is in your Sentry organization and with what role, whether they use two-factor sign-in and SSO, when they were last active, open invitations, teams and who is on them, projects and their client keys (DSNs), every outside service and app connected to Sentry with the permissions it holds, where error data is sent outside Sentry by service hooks and data forwarding, the organization's security settings, and the audit log of who changed what. ConfigView only reads. It never creates, changes or deletes anything, and it never reads issues, events, stack traces, replays or key secrets.

***

## Step 1: Open the Sentry page in ConfigView

Open ConfigView in a second browser tab and leave it open:

`https://{companyname}.configview.com/admin/integrations/sentry`

***

## Step 2: Find your organization slug and address

1. Sign in to Sentry and open **Settings → General Settings**
2. Copy **Organization Slug** (it is also the first part of your Sentry address, `https://<slug>.sentry.io/`). Paste it into `SENTRY_ORG_SLUG` under **Credentials** and click the save icon
3. On the same page, look at **Data Storage Location**:

| Data Storage Location | `SENTRY_BASE_URL` |
| - | - |
| United States (US) | leave it empty |
| European Union (EU) | `https://de.sentry.io` |
| Self-hosted Sentry | your Sentry address, for example `https://sentry.yourcompany.com` |

***

## Step 3: Create an internal integration for ConfigView

You need to be an organization **Owner** or **Manager** to create one.

1. Open **Settings → Developer Settings → Custom Integrations** and click **Create New Integration**
2. Choose **Internal Integration** and click **Next**
3. **Name:** `ConfigView`. Leave **Webhook URL** empty and **Alert Rule Action** off
4. Under **Permissions**, set:

| Resource | Permission |
| - | - |
| Project | **Read** |
| Team | **Read** |
| Release | No Access |
| Issue & Event | No Access |
| Organization | **Read** (or **Read & Write** for the audit log, see below) |
| Member | **Read** |
| Alerts | No Access |

5. Leave every **Webhooks** box unticked and click **Save Changes**
6. Under **Tokens**, copy the token. Switch to the ConfigView tab, paste it into `SENTRY_AUTH_TOKEN` under **Credentials**, and click the save icon

**The audit log needs Organization: Read & Write.** Sentry only shows the audit log to tokens that can also change organization settings. ConfigView never makes a change, but the token could. If that is more than you want to grant, leave Organization on **Read**: everything else is collected and the audit log table stays empty.

Don't use an **Organization Token** (the `sntrys_...` tokens under **Developer Settings → Organization Tokens**). Those are built for uploading source maps and can't read members, teams or integrations.

***

## Step 4: Connect and verify

1. Back on `https://{companyname}.configview.com/admin/integrations/sentry`, confirm the credentials show as saved
2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**:

| Script | Notes |
| - | - |
| **Organization Settings** | The Sentry organization's security settings: whether two-factor sign-in and SSO are required, open team membership, the default role for new members, who may invite people or create projects, data scrubbing, and which region the data is stored in. |
| **Members** | Everyone in the Sentry organization and every open invitation: email, organization role (owner, manager, admin, member, billing), whether two-factor sign-in is on, whether the account is linked to SSO or provisioned by the identity provider, who invited them, and when they last signed in and were last active. |
| **Teams** | Sentry teams: name, how many members each has, the projects it owns, and whether the identity provider manages it. |
| **Team Members** | Who is on each Sentry team and whether they are a team admin or a contributor. Runs after **Teams**. |
| **Projects** | Sentry projects: name, platform, the teams that own each one, when it was created and when it first received an error. |
| **Client Keys (DSNs)** | The client keys (DSNs) apps use to send errors to each Sentry project: key name, project, whether it is active and its rate limit. Only the key's public ID is stored, never its secret or the DSN. Runs after **Projects**. |
| **Integrations** | Outside services connected to Sentry - GitHub, GitLab, Slack, Jira, PagerDuty, Microsoft Teams, Vercel and others: the account each one is connected to, its status and the permissions it was granted. No credentials are stored. |
| **Installed Apps** | Apps installed on the Sentry organization through Sentry's integration platform, including internal integrations your own team built: who made each one, what it may read or change in Sentry, and the host its webhooks go to. Tokens and secrets are never stored. |
| **Service Hooks** | Webhooks set on Sentry projects that send every new error or alert to an outside address: the project, which events are sent, and the host they go to. The full URL and signing secret are not stored. Runs after **Projects**. |
| **Data Forwarding** | Where Sentry copies error data outside itself through Data Forwarding - Amazon SQS, Segment or Splunk: the provider, whether it is on, which projects are included and the host, queue region or bucket it sends to. Access keys and tokens are never stored. |
| **Audit Log** | Who changed what in Sentry: members invited, removed or given a new role, integrations and apps added or removed, projects and teams created or deleted, settings changed - with the time, the person or app that did it and the IP address. Kept as a growing history. Needs the token's Organization permission set to Read & Write. |

3. Click **Verify now**. The health check confirms the token can read your organization, then reads one record from each kind of data.

If a check fails:

* **"Sentry organization" fails with 401.** The token is wrong, or the internal integration was deleted (that revokes its tokens). Create a new token under the integration's **Tokens** section.
* **"Sentry organization" fails with 404.** `SENTRY_ORG_SLUG` is not an organization this token belongs to. Check the slug, and for self-hosted Sentry set `SENTRY_BASE_URL`.
* **"Members", "Teams" or "Projects" fails with "needs ... Read".** That permission is set to **No Access** on the internal integration. Change it to **Read**, save, and verify again. The token updates in place.
* **"data is stored at [https://de.sentry.io](https://de.sentry.io)".** Your organization's data lives in the EU. Set `SENTRY_BASE_URL` to `https://de.sentry.io` so ConfigView's requests stay in that region.
* **"Audit log" is skipped.** The integration's Organization permission is **Read**. Set it to **Read & Write** if you want the audit log (Step 3). Everything else still works.
* **"Data forwarding" is skipped.** Data Forwarding isn't part of your Sentry plan, or nothing has been set up. The table stays empty and nothing fails.

***

## Data Tables

Once the scripts run, these tables are created in your database. Each includes a `run_at` column. Every table keeps only the newest run, except `sentry_audit_logs`, which keeps every entry ever collected.

| Table | Source | Key Columns |
| - | - | - |
| `sentry_organization` | `GET /api/0/organizations/{org}/` | org\_id, slug, name, require\_2fa, require\_email\_verification, has\_auth\_provider, open\_membership, default\_role, allow\_member\_invite, allow\_member\_project\_creation, allow\_join\_requests, allow\_superuser\_access, allow\_shared\_issues, enhanced\_privacy, data\_scrubber, scrape\_javascript, events\_member\_admin, alerts\_member\_write, region\_url, features |
| `sentry_members` | `GET /api/0/organizations/{org}/members/` | member\_id, user\_id, email, name, org\_role, pending, expired, invite\_status, inviter\_name, user\_active, has\_2fa, has\_password\_auth, is\_managed, sso\_linked, sso\_invalid, idp\_provisioned, idp\_role\_restricted, date\_created, date\_joined, last\_login, last\_active |
| `sentry_teams` | `GET /api/0/organizations/{org}/teams/` | team\_id, slug, name, member\_count, project\_count, project\_slugs, idp\_provisioned, date\_created |
| `sentry_team_members` | `GET /api/0/teams/{org}/{team}/members/` | team\_id, team\_slug, member\_id, user\_id, email, name, team\_role, org\_role |
| `sentry_projects` | `GET /api/0/organizations/{org}/projects/` | project\_id, slug, name, platform, status, team\_slugs, team\_count, is\_public, date\_created, first\_event, has\_replays, features |
| `sentry_project_keys` | `GET /api/0/organizations/{org}/project-keys/` | key\_id, name, project\_id, project\_slug, is\_active, rate\_limit\_count, rate\_limit\_window, browser\_sdk\_version, date\_created |
| `sentry_integrations` | `GET /api/0/organizations/{org}/integrations/` | integration\_id, provider\_key, provider\_name, name, domain\_name, account\_type, status, org\_integration\_status, external\_id, scopes, features, grace\_period\_end |
| `sentry_app_installations` | `GET /api/0/organizations/{org}/sentry-app-installations/`, `GET /api/0/sentry-apps/{app}/` | installation\_uuid, install\_status, app\_slug, app\_name, author, app\_status, is\_internal, scopes, scope\_count, has\_write\_scope, events, webhook\_host, redirect\_host, is\_alertable, is\_disabled, owner\_slug |
| `sentry_service_hooks` | `GET /api/0/projects/{org}/{project}/hooks/` | hook\_id, project\_id, project\_slug, status, events, url\_host, date\_created |
| `sentry_data_forwarders` | `GET /api/0/organizations/{org}/forwarding/` | forwarder\_id, provider, is\_enabled, enroll\_new\_projects, enrolled\_project\_count, enrolled\_projects, target\_host, region, bucket, date\_added, date\_updated |
| `sentry_audit_logs` | `GET /api/0/organizations/{org}/audit-logs/` | entry\_id, event\_time, event\_name, actor\_id, actor\_name, actor\_email, ip\_address, note, target\_object, target\_user\_id, target\_user\_email, target\_name, target\_slug |

***

## Things worth knowing

**Invitations are members too.** `sentry_members` includes invitations that haven't been accepted yet (`pending = 1`). They have an email and a role but no user, sign-in or two-factor status. An invitation whose link has run out shows `expired = 1`.

**Two-factor status comes from the person's Sentry account.** `has_2fa` is whether the member has two-factor sign-in on their Sentry account. Whether the organization requires it is `sentry_organization.require_2fa`. Members who sign in through SSO are usually covered by your identity provider's own MFA instead; check `sso_linked`.

**Internal integrations are installed apps.** Every internal integration in the organization, including the one ConfigView uses, appears in `sentry_app_installations` with `is_internal = 1` and the scopes its token carries. `has_write_scope = 1` marks any app that may change something in Sentry.

**Webhook and forwarding destinations are stored as hosts.** `webhook_host`, `url_host` and `target_host` are the host data is sent to, never the full URL, which can carry a token. Data forwarding credentials (AWS access keys, Segment write keys, Splunk tokens) are never read into a table.

**Service hooks are a plan feature.** Only projects whose plan includes service hooks are asked; others are skipped without failing the run.

**The audit log is incremental.** The first run reads up to a year back. Each later run reads from the newest stored entry, and entries are never deleted from the table. Without Organization: Read & Write on the integration the table stays empty and nothing fails.

**EU organizations.** If your Data Storage Location is the EU, set `SENTRY_BASE_URL` to `https://de.sentry.io`. Requests to `sentry.io` still work, but going to the regional address keeps them inside the region.

**Rate limits.** Sentry sets limits per caller and endpoint and reports them on every response. ConfigView sends one request at a time, paces itself well below the limits and waits for the reset when one is nearly used up.

## What isn't collected

* The internal integration's token or any other token, client secret or webhook signing secret
* Client key secrets and DSN URLs. Only each key's public ID, name and settings
* Webhook URLs (only the host) and custom webhook headers
* Data forwarding configuration beyond where the data goes: no access keys, write keys or tokens
* Issues, events, stack traces, breadcrumbs, attachments, session replays and user feedback
* Integration configuration details beyond the connected account's name and the permissions granted


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.