Sethu: The Bridge for API Breaking Changes

An API upgrade can break applications in places that are difficult to find. A specification diff identifies what changed, but developers still need to locate affected code, understand the impact, repair integrations, and test the result. That work becomes harder when several changes arrive together. Sethu bridges the gap between detecting a breaking change and proving that a consumer application has adapted. It combines a Rust CLI with an IBM Bob pack to bring a structured API upgrade workflow into the developer’s workspace. The workflow starts with /api-upgrade OLD NEW in IBM Bob. Sethu uses Vimanam to compare OpenAPI specifications, then helps trace the reported changes into the consumer application. Bob supports the repair workflow, while Sethu records evidence that an independent checker validates. Sethu targets developers who maintain API clients, service integrations, and applications that depend on evolving APIs. Instead of manually connecting a specification report to scattered application code, they work through the upgrade within their development environment. Its distinctive feature is the separation between making a repair and verifying it. An assistant’s explanation does not count as proof. Verification requires matching execution evidence, and unsupported cases block a verification claim. Sethu also preserves Vimanam’s original change identifiers and severities, keeping each repair connected to the change that prompted it. This approach makes API migration more traceable and reviewable. Vimanam supplies the API change analysis, IBM Bob provides the developer interaction, and Sethu connects the workflow to recorded evidence. The aim is to reduce repetitive investigation while giving developers a stronger basis for deciding whether an upgrade is ready.