Dovkie
Sign in
Back to monitors

sentry

Sentry API

REST
OpenAPI (JSON)
https://raw.githubusercontent.com/getsentry/sentry-api-schema/main/openapi-derefed.json
Breaking AI classification

Remove segment_names field from Replay responses; add webhookEvents to SentryApp

This diff makes two distinct changes:

  • segment_names removed: The segment_names field (nullable array of strings) is removed from Replay response schemas across multiple endpoints, and segment_names is also removed from the valid enum values for the field query parameter. Clients requesting segment_names as a field or reading it from replay responses will break.
  • webhookEvents added: A new webhookEvents field (array of strings, e.g. issue.assigned, issue.created, etc.) is added to SentryApp response schemas and marked as required in the required array. This is a new response field that existing integrations can now read, but its addition to required means schema validators may flag existing responses that omit it.

Alert history

  • Breaking

    Remove segment_names field from Replay responses; add webhookEvents to SentryApp

    This diff makes two distinct changes:

    • segment_names removed: The segment_names field (nullable array of strings) is removed from Replay response schemas across multiple endpoints, and segment_names is also removed from the valid enum values for the field query parameter. Clients requesting segment_names as a field or reading it from replay responses will break.
    • webhookEvents added: A new webhookEvents field (array of strings, e.g. issue.assigned, issue.created, etc.) is added to SentryApp response schemas and marked as required in the required array. This is a new response field that existing integrations can now read, but its addition to required means schema validators may flag existing responses that omit it.
  • Additive

    Add segment_names field to session response

    A new optional response field segment_names (array of strings, nullable) has been added to session objects across multiple API responses. This field can now be marshaled in output by including it in field query parameters, and clients can optionally consume it without breaking existing integrations.

  • Informational

    Remove alerts aspect info text from PagerDuty and Slack integration examples

    The aspects.alerts array (containing informational type: info text blurbs) has been removed from the PagerDuty and Slack integration metadata examples in the OpenAPI spec, replaced with an empty aspects: {} object. These are example/documentation values in the spec rather than a schema change, so existing integrations are unlikely to break — but clients that parse or display aspects.alerts from the API response may now receive an empty object instead of the info alert array.

  • Additive

    Add outOfDate field to integration responses

    A new optional boolean field outOfDate has been added to integration response schemas across multiple endpoints. The field is nullable and included in example responses with a false value, allowing API clients to determine if an integration configuration is outdated. This is a purely additive change that does not affect existing integrations.

  • Additive

    Add optional download parameter to get attachment endpoint

    The GET /api/0/projects/{organization_id_or_slug}/{project_id_or_slug}/events/{event_id}/attachments/{attachment_id}/ endpoint now supports an optional download query parameter that triggers binary file download instead of returning JSON metadata. This is purely additive—existing callers without the parameter continue to work unchanged.

  • Informational

    Remove availability disclaimer from alert trigger descriptions

    The phrase "Note: seer_activity_trigger may not be available to all organizations." was removed from three identical alert trigger description fields in the OpenAPI schema. This is a documentation clarification that does not change the actual API behavior, endpoints, or response/request shapes.

  • Additive

    Add enum constraints to level field in event responses

    The level field in multiple event response schemas now includes explicit enum constraints listing valid values: "sample", "debug", "info", "warning", "error", "fatal", and "unknown". This change documents previously implicit constraints without removing any existing values, making the API contract more explicit and enabling better client validation.

  • Additive

    Expand occurrence object schema with detailed field definitions

    The occurrence field in multiple event response schemas is now fully documented with explicit property types, replacing an empty object definition. Previously defined as {} (any type), it now specifies a detailed structure including id, projectId, eventId, fingerprint, issueTitle, subtitle, resourceId, evidenceData, evidenceDisplay, type, detectionTime, level, culprit, assignee, and priority fields. This is a documentation enhancement that does not break existing clients since the field was already present; it simply makes the structure more explicitly defined in the OpenAPI schema.

  • Additive

    Add canvas_theme field to image objects, rename content_hash to key

    The Sentry API adds an optional canvas_theme field (enum: "light", "dark", null) to multiple image object schemas across replay and network monitoring endpoints. Additionally, the content_hash field is renamed to key in head_image and base_image objects. These are additive changes to response schemas that enable clients to specify or receive canvas theme information for replay images.

  • Additive

    Document groupingConfig object schema in event responses

    The groupingConfig field in event response schemas is now documented with explicit type information and required properties (id and enhancements). Previously it was defined as an empty object schema. This change clarifies the structure of event responses and helps clients understand what data they can expect, with no breaking changes to existing integrations.

  • Additive

    Add integration issue config and linking endpoints

    Added three new endpoints for managing integration-linked issues: a GET endpoint to retrieve issue configuration forms for creating or linking external issues, a POST endpoint to create or link external issues, and a DELETE endpoint to unlink external issues. These are purely additive and fully backward-compatible; existing integrations continue to work unchanged.

  • Additive

    Add seer_activity_trigger option to alert conditions

    The Sentry API now documents a new seer_activity_trigger condition type for alert triggers, which accepts comparison values for RCA (root cause analysis) workflow events (rca_started, rca_completed, etc.). This is an additive change that extends the available trigger conditions; a note clarifies the feature may not be available to all organizations yet.

  • Additive

    Add enum constraints to issue and chart fields

    The API schema adds enum constraints to response fields status, substatus, priority, confidence, and legendType across multiple endpoints and schemas. These fields were previously typed as plain strings but are now restricted to specific valid values. Since these changes add documentation of already-constrained values in responses (not modifying request contracts or narrowing accepted inputs), existing integrations reading responses with these values will continue to work.

  • Additive

    Add relayDsnEndpoint field to organization response

    The Sentry API adds a new optional nullable relayDsnEndpoint field to organization response schemas, allowing clients to retrieve the Relay base URL used for displaying Client Key DSNs. This is a purely additive change that does not affect existing integrations.

  • Informational

    Update example measurements in transaction schema

    The OpenAPI schema example for the measurements field in transaction objects has been expanded to include concrete measurement examples (measurements.frames_slow_rate and measurements.frames_frozen_rate). This is a documentation-only change that illustrates additional measurement types supported by the API without altering any actual endpoints or breaking existing integrations.

  • Additive

    Add listOrganizationReleases endpoint and release schemas

    A new endpoint GET /api/0/organizations/{organization_id_or_slug}/releases/ has been added to list organization releases with filtering by project, environment, and query parameters. Several new schema definitions have also been added to support this endpoint, including ReleaseFile, ReleaseFileUpload, ReleaseHeadCommitSerializerDeprecated, and ReleaseSerializerWithProjects. These are purely additive changes that do not affect existing integrations.

  • Additive

    Add isConvention field to attribute context metadata

    The Sentry API now includes a new optional isConvention boolean field in the context object for attributes, along with updated documentation clarifying how attribute metadata is sourced from Sentry conventions by name and type. This is a backward-compatible addition that provides clients with information about whether an attribute matches a known convention.

  • Additive

    Add optional webhookHeaders field to Sentry integrations

    Added a new optional webhookHeaders field (array of strings) to custom integration response schemas and request schemas across multiple integration endpoints. This allows integration webhooks to include custom headers without breaking existing integrations that don't use this field.

  • Informational

    Clarify data-browsing-attribute-context feature gate documentation

    The context field description in the API schema has been updated to clarify when the data-browsing-attribute-context feature gate applies. The change restructures the documentation text but does not alter the actual API behavior, endpoints, or response structure — it is purely a documentation improvement for clarity.

  • Breaking

    Remove plugin-related fields from issue and project API responses

    The fields pluginActions, pluginIssues, pluginContexts, and plugins have been removed from multiple response schemas. These were previously required/documented fields on issue detail and project detail responses — clients that read or depend on any of these fields will encounter missing data. The pluginActions and pluginIssues enum values have also been removed from the expand query parameter on issue endpoints.

  • Additive

    Add mobile_app_vital field to transaction objects

    A new optional mobile_app_vital field has been added to transaction response objects in the Sentry API. This field mirrors the existing browser_web_vital structure, allowing clients to capture mobile application performance metrics like cold start, warm start, time to interactive, and time to fully drawable. Existing integrations are unaffected as this is a purely additive change.

  • Informational

    Clarify snapshot image categorization behavior in docs

    The getOrganizationPreprodArtifactSnapshot endpoint description was updated to clarify how images are organized based on comparison_type. The documentation now explicitly states that when a comparison exists (comparison_type is diff), the top-level images array is empty and images appear in categorized lists (changed, added, removed, etc.), while for solo and waiting_for_base snapshots the categorized lists are empty and only the images array is populated. The example response was also updated to reflect this with an empty images array.

  • Breaking

    Remove required fields 'brief' and 'isDeprecated' from context object

    The required constraint on the context response object has been removed, meaning brief and isDeprecated are no longer guaranteed to be present. Clients that assumed these fields were always present (e.g. accessing them without null-checks) may encounter runtime errors. The description update clarifies that custom attributes now receive an empty context, which explains why these fields can no longer be required.

  • Breaking

    project query param type changed from integer to string

    The project query parameter type was changed from integer to string, and its description updated to accept either an ID or a slug. Clients that validate or serialize this parameter as a strictly numeric/integer type may break, though passing an integer as a string is typically backwards-compatible in practice. The broader concern is any strict-typed SDK or client that enforces the integer schema.

  • Additive

    Add seerMatchDistance field to group hash response

    The API now includes a new seerMatchDistance field (nullable double) in group hash responses. This field indicates the match distance score when hashes are merged by Seer. The field is required in the schema but nullable in value, allowing clients to handle cases where a match distance is not available.

  • Additive

    Add optional context field to attribute metadata endpoints

    A new optional context field has been added to attribute response objects in two endpoints, providing additional metadata about Sentry conventions when the expand=context parameter is passed and the data-browsing-attribute-context feature is enabled. This field includes brief, isDeprecated, details, examples, and replacementAttribute properties, none of which break existing integrations since the field is optional and only populated under specific conditions.

  • Additive

    New required field `browser_web_vital` added to span response objects

    A new browser_web_vital field (type object) has been added to span response objects in two schema locations. It is listed as required in the response schema, meaning the API will always return it — this is additive for consumers reading the field, but clients doing strict schema validation against the old spec (which lacked this field) may need to update their models. The field contains browser Core Web Vitals metrics such as browser.web_vital.lcp.value, browser.web_vital.cls.value, browser.web_vital.inp.value, browser.web_vital.ttfb.value, and browser.web_vital.fcp.value.

  • Informational

    operationId refactoring: camelCase IDs and added summary fields

    All operationId values have been converted to camelCase (e.g. listOrganizations, getOrganization) and matching summary fields have been added to preserve the original human-readable titles. This is a purely internal documentation reorganization — operationId is not a versioned API contract and does not affect request/response behavior.

  • Breaking

    Filter rule `id` field type changed from string to integer

    The id field on filter/rule group objects has been retyped from "type": "string" to "type": "integer" in 7 places across the spec. Clients that treat this field as a string (e.g. storing it as "123", comparing with ===, or passing it in a string-typed variable) will break when the API returns or requires a numeric value instead.

  • Additive

    Add optional team name field and query parameters

    Added optional name field to team objects (max 64 chars), marked two endpoints as deprecated (Submit User Feedback and List a Project's Issues), and added new optional query parameters sort and limit to the issues endpoint plus project and per_page to an unspecified releases/projects endpoint. These changes are additive; deprecation markers inform clients of planned removals without breaking existing functionality.

  • Additive

    Add optional per_page query parameter to listing endpoints

    Two listing endpoints now accept an optional per_page query parameter to control pagination result size. The parameter accepts integer values with a default and maximum of 100. This is a purely additive change that allows clients more control over pagination without affecting existing code.

  • Additive

    Add pr_iteration to autofix step enum

    A new enum value pr_iteration has been added to the autofix step parameter in two Sentry API endpoints. This is an additive change that allows clients to use a new optional step type without breaking existing integrations that use the previous enum values.

  • Additive

    Monitor and Notification Action endpoints now accept project IDs

    The Sentry API now accepts project IDs in addition to project slugs for monitor and notification action endpoints. The project parameter schema for monitors is expanded to accept both integer (ID) and string (slug) types, and documentation is updated across multiple endpoints to reflect this new capability. This is backward compatible and enables additional flexible project identification.

  • Additive

    Allow project slugs in addition to IDs in query filters

    The project query parameter on three endpoints now accepts both integer project IDs and string project slugs (via anyOf schema union), whereas it previously accepted only integers. This is backward-compatible because existing integer-based code will continue to work. Additionally, documentation for the yAxis parameter on the timeseries endpoint was expanded with detailed examples of available aggregation functions, and a note about accuracy limitations for certain query patterns was added to the endpoint description.

  • Additive

    Add heatmap visualization type option

    A new enum value heatmap has been added to visualization type fields across multiple dashboard/widget endpoints in the Sentry API. This is a purely additive change that expands the available visualization options without breaking existing integrations that use other visualization types.

  • Deprecation

    Deprecate project_id query param; add project param

    The project_id query parameter is now deprecated on release endpoints in favor of a new project parameter that accepts both integer IDs and string slugs. The new project parameter overrides project_id when both are provided, allowing more flexible project filtering.

  • Additive

    Accept project slugs in project filter parameter

    The project query parameter now accepts both integer project IDs and string project slugs (e.g., android or javascript-react), expanding the ways to filter events and issues. Additionally, the Autofix API now includes a new sentry_run_id (UUID) field while retaining the legacy run_id (integer) field for backward compatibility.

  • Breaking

    GET endpoint for downloading snapshot images as ZIP removed

    The GET /api/0/organizations/{organization_id_or_slug}/preprodartifacts/snapshots/{snapshot_id}/download/ endpoint has been removed from the API spec. Any clients calling this endpoint to download snapshot images as a ZIP archive will receive a 404 or routing error, breaking their integration.

  • Breaking

    Remove `setupDialog` field from integration provider response schema

    The setupDialog field has been removed from the integration provider object schema in the response for listing available integrations. It was previously a required field (object type with additionalProperties) containing url, width, and height for the setup dialog. Any client code reading setupDialog from integration provider responses will now receive undefined/missing and may break if it doesn't guard against absence.

  • Breaking

    GetReplayRecordingSegment response changed from array to typed object

    The 200 response schema for the "Retrieve a Replay Segment" endpoint has changed from an array of arbitrary objects (array of object with additionalProperties) to a typed object with a required data property containing replayId, segmentId, projectId, and dateAdded fields. This is a breaking change: any client code iterating over the response as an array, or accessing raw segment event data (e.g. type, timestamp, data.tag), will break. The new shape wraps metadata in data and no longer returns the raw recording segment events.

  • Additive

    Allow null values in debug configuration fields

    Three debug configuration schema objects now allow null values by adding "nullable": true to their definitions. This is backward compatible — existing code sending non-null values will continue to work, and clients can now optionally handle null values for these fields.

  • Informational

    OutgoingNotificationAction schema fully defined, replacing additionalProperties

    The OutgoingNotificationAction schema (and corresponding inline response schemas for spike-protection notification action endpoints) was previously defined as "additionalProperties": {} (i.e. an opaque object). It now has explicit properties: id, organizationId, integrationId, sentryAppId, projects, serviceType, triggerType, targetType, targetIdentifier, and targetDisplay, all marked as required. Additionally, example values for id and organizationId were corrected from strings ("836501735") to integers (836501735), aligning with the new integer type declarations. This is a documentation/schema clarification — the underlying API behaviour has not changed, but client code generated from the old schema (which accepted any shape) may now be validated against a stricter schema.

  • Additive

    Add avatarUrl field to avatar objects across team endpoints

    The avatarUrl field is being added to avatar objects in multiple team-related API responses (create team, retrieve team, update team, list teams, remove member, add member). This is a purely additive change that provides an additional optional field in the response without removing or modifying existing fields, so existing clients will continue to work unaffected.

  • Breaking

    Replays list response wrapped in a `data` envelope object

    The 200 response schema for the replays list endpoint changed from a top-level array to an object with a required data property containing that array. Clients that currently index directly into the response array (e.g. response[0]) will break and must be updated to response.data[0]. A second, similar wrapping change is visible for the individual replay response schema as well.

  • Additive

    Add PUT endpoint for bulk updating project environments

    A new PUT endpoint was added to bulk update the visibility (hidden/shown) of multiple project environments at once. This is a purely additive change that allows clients to show or hide up to 1000 environments in a single request, requiring project:admin or project:write scopes.

  • Additive

    Add new fields to issue schema and structure object fields

    Two sets of additive changes to issue schemas: (1) new nullable fields matchingEventId and matchingEventEnvironment added to issue objects, now marked as required in the schema; (2) the inbox, owners, and sentryAppIssues object fields previously defined as open objects (additionalProperties: {}) are now explicitly structured with defined properties and required fields, improving schema specificity without breaking existing integrations.

  • Additive

    Add format constraints and nullable to DSN key fields

    The Sentry API schema now marks the publicKey field as nullable: true and adds format: date-time constraints to firstSeen and lastSeen fields in DSN key response schemas. These changes clarify the API contract without removing or breaking existing functionality — clients already handling these fields will continue to work.

  • Additive

    Add optional project query parameter

    A new optional project query parameter has been added to filter results by project IDs (as an array of integers). This is purely additive and provides an alternative way to filter by projects; existing integrations using the existing project_id_or_slug parameter continue to work unchanged.

  • Informational

    Add pagination documentation links to cursor parameter

    Added x-learn-more metadata field pointing to pagination documentation (https://docs.sentry.io/api/pagination/) to the cursor query parameter across 30 endpoints. This is a documentation enhancement that does not alter the API's functional behavior or response schemas.

  • Breaking

    GET /api/0/projects/.../users/ response schema expanded with required fields

    The GET /api/0/projects/{organization_id_or_slug}/{project_id_or_slug}/users/ endpoint's response schema was replaced with a much richer object. The old schema only required username (nullable) and email (nullable); the new schema requires 8 additional non-nullable fields: avatarUrl, dateCreated, hash, id, identifier, ipAddress, name, and tagValue. Additionally, the required OAuth scope changed from project:read alone to project:admin, project:read, or project:write, and the cursor parameter now has minLength: 1. Clients that previously received only username/email may need to handle the new shape, and tooling that validated the old minimal schema will now see unexpected required fields.