Sentry
Turn incidents and requests into Sentry work items, and keep status in step across your tools.
27 ways to read, 4 ways to write, each write switched on by you.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with Sentry, an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Record deployApproval by rule
- Create releaseApproval by rule
- List alertsRead
Example flow
- Sentry · List alertsDone
- Sentry · Record deployNeeds approval
- Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches Sentry.
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to Sentry
- Sentry's reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect your own account when you are ready to go live.
For developers
Technical detail
Sentry projects, teams, members, issues and events, releases, commits and deploys, alerts, monitors, cron check-ins and session replay metadata; triage issues and record releases.
Sentry API docs- Source actions
- 27
- Destination actions
- 4
- Data types
- 18
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
Alerts2
- Get alertSource
One alert (workflow) with its triggers and actions.
- List alertsSource
Alerts (workflows) with their triggers, actions and last trigger time.
Detectors1
- List issue monitorsSource
Monitors (detectors) that create issues, such as metric, uptime and cron detectors.
Environments1
- List project environmentsSource
Environments seen in a project.
Events1
- Get eventSource
One event in a project with release, SDK and exception summary.
Issue events2
- Get issue eventSource
The latest, oldest or recommended event of an issue, or one event by ID.
- List issue eventsSource
Individual events (occurrences) of an issue, newest first.
Issues3
- Get issueSource
One issue with status, assignee, priority and counts.
- List issuesSourceIncremental
Issues (grouped errors and performance problems) across the organisation, with status, assignee and counts.
- Update issueDestinationProvider duplicate protectionApproval before production
Resolves, ignores or reopens an issue, assigns it, or sets priority, bookmark and seen state.
Members2
- Get memberSource
One organisation member with role and teams.
- List membersSource
Organisation members with role and invitation state.
Monitor checkins1
- List cron check-insSource
Check-ins reported for a cron monitor, newest first.
Monitors2
- Get cron monitorSource
One cron monitor by slug or ID.
- List cron monitorsSource
Cron monitors with schedule and per-environment check-in status.
Organization1
- Get organisationSource
The configured organisation's name, status and security settings.
Project events1
- List project error eventsSource
Error events in a project, newest first.
Projects2
- Get projectSource
One project with its teams, platform and latest release.
- List projectsSource
Projects in the organisation.
Release commits1
- List release commitsSource
Commits associated with a release.
Release deploys2
- Record deployDestinationNot retried automaticallyApproval before production
Records that a release was deployed to an environment.
- List release deploysSource
Deploys of a release to environments.
Releases4
- Create releaseDestinationProvider duplicate protectionApproval before production
Creates a release for one or more projects. An existing version is returned unchanged (HTTP 208).
- Get releaseSource
One release with commit, deploy and new issue counts.
- List releasesSource
Releases in the organisation with new issue, commit and deploy counts, newest first.
- Update releaseDestinationProvider duplicate protectionApproval before production
Sets the reference, URL or release date of an existing release.
Replays2
- Get session replaySource
Metadata for one session replay. User details, URLs and recordings are not requested.
- List session replaysSource
Session replay metadata (timing, error counts, browser and release). User details, URLs and recordings are not requested.
Team members1
- List team membersSource
Members of one team with their team role.
Teams2
- Get teamSource
One team with its member count and projects.
- List teamsSource
Teams in the organisation with member counts.
Access and limits
- Authentication
- Auth token (internal integration or user token)
- Plans and access
- All Sentry SaaS plans, including Developer. Organisation auth tokens and internal integration tokens are limited to their scopes; user auth tokens follow the user's membership.
- Test environment
- A free Developer plan organisation works for testing.
- Rate limits
- Per-endpoint, per-organisation limits reported in X-Sentry-Rate-Limit headers; HTTP 429 with Retry-After.
- Pagination
- Link header cursors; Nexra follows rel="next" only while results="true".
- Provider events
- Integration platform webhooks for issue, error, event alert and comment events. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.
Before you build a flow
- Self-hosted Sentry is not supported by this recipe.
- Merging, deleting and discarding issues, release and monitor deletes, and replay deletion jobs are intentionally not implemented.
- Alerts and monitors are read-only; creating or changing alert rules, detectors and cron monitors is not implemented.
- Replays return metadata only: Nexra requests a fixed field list without user, URL, click or tag data, and never downloads recording segments.
- Event reads omit stack frames, breadcrumbs, request bodies and contexts.
- Issue lists cover the statsPeriod window (14 days by default, up to 90d); lastSeen filters are applied through the Sentry search query.
- Deploy creation has no idempotency key; uncertain writes are not repeated automatically.
Developer reference
- Create the Sentry credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose Sentry, enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/sentry and the Connections API.