How does API versioning strategy differ for internal microservice-to-microservice APIs versus public-facing external APIs?

Internal APIs, where the team controls both producer and consumer and can coordinate deployments, often favor looser versioning (or none at all) relying on contract testing and coordinated rollouts, sometimes accepting brief compatibility windows during deploys. Public external APIs, where consumers are unknown, numerous, and can't be coordinated with directly, require much stricter, longer-lived versioning with generous deprecation windows and strong backward-compatibility guarantees, since a breaking change can silently fail for consumers you don't even know about.

// Internal service-to-service: looser, coordinated deploys
// Both OrderService and InventoryService deploy together, contract tests catch mismatches in CI

// Public external API: strict versioning, long deprecation windows
// /api/v1 supported for 12+ months after v2 launches, with proactive client communication