در مهندسی نرم‌افزار، API Compatibility یعنی یک نسخه‌ی جدید از API تا چه حد می‌تواند بدون خراب کردن کدهای قبلی، جایگزین نسخه‌ی قبلی شود.
مثلاً فرض کن API قبلی این endpoint را دارد:

GET /users/123

و پاسخ می‌دهد:

{
  "id": 123,
  "name": "Ali"
}

اگر در نسخه‌ی جدید همچنان همین endpoint و فیلدها را حفظ کنی، معمولاً backward compatible هستی.
اما اگر تبدیلش کنی به:

GET /user/123

یا name را حذف کنی، کلاینت‌هایی که با نسخه‌ی قبلی کار می‌کردند ممکن است بشکنند؛ پس breaking change ایجاد کرده‌ای.
چند نوع مهم Compatibility
1. Backward Compatibility
نسخه‌ی جدید API می‌تواند کلاینت‌های قدیمی را پشتیبانی کند.
مثلاً اضافه کردن یک فیلد جدید:

{
  "id": 123,
  "name": "Ali",
  "email": "ali@example.com"
}

معمولاً مشکلی برای کلاینت قدیمی ایجاد نمی‌کند، چون email را نادیده می‌گیرد.
2. Forward Compatibility
سیستم قدیمی بتواند تا حدی با داده‌ها یا API جدیدتر کنار بیاید. این معمولاً سخت‌تر از backward compatibility است.
3. Source Compatibility
کدی که با API قبلی نوشته شده، بدون تغییر بتواند compile شود.
مثلاً اگر در Java این را داشته باشیم:

user.getName();

و در نسخه‌ی جدید getName() را حذف کنیم، source compatibility شکسته می‌شود.
4. Binary Compatibility
برنامه‌ای که قبلاً compile شده، بتواند با نسخه‌ی جدید library اجرا شود، بدون اینکه دوباره compile شود.
نکته‌ی خیلی مهم
وقتی در پروژه می‌گویند:

"Is this API change compatible?"

معمولاً منظورشان این است:
آیا این تغییر باعث می‌شود consumerهای فعلی API مجبور به تغییر کدشان شوند یا نه؟