Duplicate API capabilities — customer lookup, payment processing, document storage — are built multiple times in enterprises not out of laziness but because teams can't find, trust, or adopt what already exists. Reusability needs to be treated as something measurable, not just aspirational. A three-axis rubric covers interface quality (shared schemas, consistent errors, security), operational anatomy (docs, sandbox, rate limits, changelog), and composability (machine-readable workflows, agent surfaces). Semantic duplication detection surfaces overlapping capabilities that keyword search misses. Demand data from gateway logs divides the API estate into four quadrants: exemplars, load-bearing liabilities, undiscovered well-built APIs, and retirement candidates. The key reframing is that the unit of reuse is the capability, not the API — and canonical implementations should be chosen by adoption, not elegance. A free browser-based tool at reusability.apicommons.org implements this rubric, and a companion paper and governance service are also available.
