Salesforce Decode
Salesforcedecode
Back to questions
Headless 360Architect (Hardest)api-versioningdeprecationpartnersgovernance

Design API versioning and deprecation for public partner APIs

Real World Scenario

200 partners consume your Salesforce-backed product catalog API. A breaking schema change for new attributes threatens partner integrations.

Expected Answer

• Semantic versioning with minimum 12-month deprecation notice for breaking changes • Parallel v1/v2 endpoints during migration window with usage telemetry per version • Additive changes only in minor versions—never remove fields without major version • Partner developer portal with changelog, sandbox keys, and contract tests • Sunset automation alerting partners still on deprecated versions • Breaking change approval board including partner success representation • Load test new versions before default routing switches

Follow-Up Questions & Answers

Click to expand — each follow-up includes a direct, interview-ready answer

Main difference: use case and scale. Semantic versioning with minimum 12-month deprecation notice for breaking changes. Parallel v1/v2 endpoints during migration window with usage telemetry per version. Pick based on your integration pattern and team capability. Public APIs are long-term contracts—architects optimize for partner stability over internal convenience. Document the decision in an ADR and align with enterprise standards.

Architect Perspective

Public APIs are long-term contracts—architects optimize for partner stability over internal convenience.