Версія у path
Поточний API використовує /api/v1. Ламаючі зміни мають отримувати нову версію або чіткий перехідний період.
Versioning і changelog.
Як Limvero має змінювати public API без непередбачуваних поломок для інтеграцій.
Політика змін
Розробник має розуміти, які зміни безпечні, які потребують міграції і де шукати історію API.
Additive changes first
Нові optional поля, нові endpoints і нові scopes можна додавати без ламаючої міграції, якщо старий контракт не змінюється.
Deprecation notice
Застарілі endpoints або поля мають бути описані в changelog із датою, альтернативою і строком підтримки.
Contract tests
OpenAPI, сторінки Developer Portal, Postman і SDK мають проходити перевірку синхронності в CI.
No hidden breaking changes
Зміна формату помилок, пагінації, scopes або tenant boundary без оновлення документації заборонена.
Roadmap не дорівнює Available
Future API phases показуються як roadmap і не мають потрапляти в OpenAPI як доступні production endpoints.
Поточний статус
Public API має невеликий read-only surface. Не вигадуємо історію версій і не показуємо fake changelog: зміни додаються в журнал тільки після фактичного release.Сплануйте запуск ресторану без хаосу.
Покажемо Limvero на прикладі ресторану, схожого на ваш: точки, меню, POS, кухню, QR-меню, склад, лояльність і тарифи.