Skip to main content
Suki evolves the platform through additive changes and documented deprecations. We do not use a fixed calendar for when deprecated features are removed. Timelines depend on the change, your integration, and coordination with your partnership team. This guide explains:
  • What counts as breaking vs non-breaking
  • How Suki handles deprecations
  • Where to find deprecation and removal notices
  • How to plan migrations
For the full schedule of known deprecations and removals, refer to the Deprecation list.

​
What’s a breaking change?

Breaking changes

Require updates to your integration:
  • Removing or renaming endpoints, fields, or parameters
  • Changing data types or formats
  • Making optional fields required
  • Tightening validation rules
  • Changing default behavior in a way that affects existing clients

Non-breaking changes

Work with existing code:
  • New endpoints or optional fields
  • New optional parameters
  • Performance improvements
  • Documentation clarifications
Refer to Breaking and non-breaking changes in the release and versioning policy for more information.

​
The deprecation timeline

Unlike a fixed quarterly removal schedule, Suki sets deprecation timelines per change. Your partnership team is the primary channel for migration dates, rollout guidance, and org-specific impact. When we need to make a breaking change, we follow this process:
1

Announce the deprecation

We mark the feature as deprecated in documentation, changelogs, and (for APIs) in the reference with a DEPRECATED tag. Your integration continues to work during the migration period.
2

Migration period

Old and new approaches typically run side by side. We publish migration guides, release notes, and changelog entries with replacement APIs or SDK patterns.
3

Removal when ready

We remove the deprecated feature after partners have had time to migrate. Removal timing is communicated through your partnership team and published in Release notes, product changelogs, and the Deprecation list.
If you do not hear from your partnership team about a deprecation, review the Deprecation list, product changelogs, monthly release notes, and announcements. Subscribe to release notes by RSS or email from the Release notes hub.

​
How you’ll know about changes

API endpoints use status tags described in API reference guidelines. SDK breaking changes appear in migration guides such as Migrating to Web SDK v2 and Migrating to Web SDK v3.

​
Planning your migration

When something you use is deprecated or removed:
  1. Assess impact: Find every call site, config flag, or SDK option that uses the deprecated item.
  2. Confirm timing: Ask your partnership team when removal applies to your organization if it is not listed on the Deprecation list.
  3. Implement replacements: Use the linked migration guide, changelog entry, or API reference page for the recommended alternative.
  4. Test before production: Run regression tests in staging before you deploy the update.
Product changelogs are the authoritative source for version boundaries. Monthly release notes give cross-product visibility but do not replace changelog detail. See Release notes and changelogs.

​
After removal

When a deprecated item is removed, behavior depends on the type of change:
For API error handling patterns, refer to the API error messages page.
Last modified on June 16, 2026