How We Think About API Backward Compatibility at Aurus
Compatibility Is a Promise, Not a Feature
Backward compatibility isn't a technical detail; it's a promise to everyone who integrated with you. Break it carelessly and you break their product, and their trust.
How we think about compatibility at Aurus starts from that framing: our customers' integrations are commitments we've made.
Additive Change Is Always Safe
New optional fields, new endpoints, new enum values that clients can ignore, these never break existing callers, and they're how an API evolves without pain.
We default to additive change. If a new capability can be added without touching existing behavior, that's how it ships.
Breaking Change Needs a New Version
Sometimes evolution genuinely requires breaking the old shape. When it does, the change belongs in a new version, with the old one kept alive long enough for everyone to move.
A breaking change without a migration path is a bug we've shipped to our customers, not an improvement.
Deprecate on the Customer's Timeline
Turning off an old version is the most dangerous thing an API provider does. We announce early, communicate clearly, and give real timelines measured in months, not weeks.
Aurus surfaces deprecation signals in responses and usage data, so customers can see what's ending and plan the move before anything is removed.
