Sentry setup - Configview Support

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

Sign in to Sentry and open Settings → General Settings
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
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.

Open Settings → Developer Settings → Custom Integrations and click Create New Integration
Choose Internal Integration and click Next
Name: ConfigView. Leave Webhook URL empty and Alert Rule Action off
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

Leave every Webhooks box unticked and click Save Changes
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

Back on https://{companyname}.configview.com/admin/integrations/sentry, confirm the credentials show as saved
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.

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”. 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

​Step 1: Open the Sentry page in ConfigView

​Step 2: Find your organization slug and address

​Step 3: Create an internal integration for ConfigView

​Step 4: Connect and verify

​Data Tables

​Things worth knowing

​What isn’t collected