Severity Levels
The 7 severity levels and what they mean for your integration.
Every detected change is classified into one of 7 severity levels. This determines how you're alerted and how urgently you need to act.
Severity reference
Breaking
Immediate action required. Something your integration depends on has changed in a way that will cause failures.
Examples:
- Required parameter added to an existing endpoint
- Response field removed or renamed
- Authentication method changed
- Endpoint removed without deprecation notice
Alert behavior: Instant email and/or Slack notification.
Deprecated
Action needed soon. A feature you may use has been marked for future removal.
Examples:
- Endpoint marked as deprecated with a sunset date
- Parameter deprecated in favor of a new one
- API version approaching end-of-life
Alert behavior: Instant notification. Includes sunset date when available.
Removed
Feature deleted. Something that previously existed is no longer available.
Examples:
- Endpoint permanently removed
- SDK method deleted
- Configuration option removed
Alert behavior: Instant notification.
Added
New capability. Something new is available that you might want to use.
Examples:
- New endpoint added
- New optional parameter on existing endpoint
- New response field
Alert behavior: Daily summary.
Changed
Behavior modified. An existing feature works differently now.
Examples:
- Default value changed for a parameter
- Rate limit adjusted
- Response format modified (but not breaking)
- Error message wording updated
Alert behavior: Daily summary.
Fixed
Bug fix. A previously incorrect behavior has been corrected.
Examples:
- Documented parameter now actually works
- Error response now returns correct status code
- Rate limit now enforced as documented
Alert behavior: Daily summary.
Cosmetic
No action needed. Documentation changed but API behavior is unaffected.
Examples:
- Typo fixed in docs
- Code examples updated
- Documentation reorganized
- Description text reworded
Alert behavior: Daily summary. Can be filtered out.