API-first

як ілюстрація:

post:

[[Категорія:Webhooks]]
Воно теж має бути документованим, бо внутрішні API часто стають критичними для:
Без єдиного словника API оперативно стає незрозумілим.; Мобільний застосунок майже завжди потребує API.; Середній бізнес-середовище зазвичай має кілька систем:

* номенклатуру;
* штрихкоди;
* задача на приймання;
* задача на відбір;
* переміщення;
* інвентаризацію;
* залишки;
* серійні номери;
* партії;
* статуси відвантаження.; "errors": [

delivery_city

У [[K2 ERP]] API-first має змогу бути основою інтеграційної архітектури.; "phone": "+380XXXXXXXXX",
!; Потрібно описати:

/api/v2/orders
Приклад:
Потрібно описати:
|-
| Customer
| замовник або контрагент
|-
| Order
| Замовлення клієнта
|-
| Invoice
| Рахунок на оплату
|-
| Payment
| Оплата
|-
| Shipment
| Відвантаження
|-
| SKU
| Артикул товару
|-
| External ID
| Ідентифікатор у зовнішній системі
|}

 ]

== API-first і rate limiting ==

== Приклад API сайту й ERP ==

!;== API-first у великому бізнесі ==

* імпорт 100 000 товарів;
* актуалізація 50 000 цін;
* передача залишків;
* міграція контрагентів;
* завантаження історії продажів;
* синхронізація довідників.; Призначення

 name

Для нього особливо важливі:

<pre>
== API-first і банк ==
{
Команда сайту використовує:
Public API доступний зовнішнім розробникам або клієнтам.; Приклад помилки:

<pre>

* які помилки можна повторювати;
* скільки разів повторювати;
* з якою паузою;
* коли відправляти в ручну перевірку;
* як не створити дублікати;
* як функціонує idempotency key.; Відповідь:
AI-рішенням потрібен контрольований доступ до даних.; Статус

Через API можна:

"edrpou": "12345678",

{

Погано:

API-first потрібен, щоб системи могли стабільно й передбачувано взаємодіяти.; Питання
{| class="wikitable" style="width:100%;"
/api/v1/orders
 {
Для створення замовлення має змогу бути описаний endpoint:
 "deleted_at": "2026-05-15T10:30:00Z"
 {
 "order_id": "MOCK-000001",

API-first сприяє розділити роботу команд:

"currency": "UAH"

Пов’язана сторінка: MES система Потрібно:

API-first і інтеграційні журнали

"order_id": "ERP-000145",

API-first і REST

Пов’язана сторінка: Service Desk

Прямий доступ до бази часто здається простішим, але створює ризики.; !; Коментар
!; інформаційні дані

}

== API-first і internal API ==

* замовлень сайту;
* клієнтів CRM;
* платежів банку;
* товарів WMS;
* виробничих завдань MES;
* документів BAS;
* міграційних записів;
* ТТН доставки.;<pre>

* перейменувати поле;
* змінити тип даних;
* видалити поле;
* змінити формат дати;
* змінити логіку статусів;
* змінити авторизацію без перехідного періоду.;== API-first і бізнес-правила ==

Потрібно підготувати:

• customer-service;
• order-service;
• payment-service;
• warehouse-service;
• notification-service;
• analytics-service;
• identity-service;
• approval-service.; бізнес-середовище має погоджувати зміст API.; API має змогу повернути:

"message": "Product with SKU USB-C-1M-BLK was not found",

• дату зміни;
• версію;
• що додано;
• що змінено;
• що застаріло;
• коли буде видалено;
• кого стосується;
• приклади міграції.; Приклади:

Сценарії:

• сайт читає таблиці ERP напряму;
• Power BI бере інформаційні дані з бойових таблиць без контролю;
• інтеграційні функціональні можливості змінює записи напряму;
• немає аудиту;
• немає валідації.; API-first надає можливість AI-асистенту отримувати:

Замість того щоб спочатку створити інтерфейс, базу даних або внутрішню логіку, а потім “якось” відкрити доступ назовні, команда спочатку описує:

• не створює новий платіж;
• повторює запит через 1 хвилину;
• потім через 5 хвилин;
• потім створює задачу в Service Desk.; | OpenAPI, версіонування, права доступу, зовнішні ID, ідемпотентність, аудит, моніторинг і тестування.; Для кожного API потрібен власник.; Потрібно фіксувати:

• частоту запитів;
• обсяг даних;
• кешування;
• індекси;
• пагінацію;
• batch-операції;
• асинхронні задачі;
• черги;
• таймаути;
• retry-логіку;
• rate limiting.;== Приклад code-first проблеми ==

• endpoint-и в множині: /orders, /customers;
• поля в snake_case або camelCase;
• статуси в нижньому регістрі;
• коди помилок у верхньому регістрі;
• однакові назви для однакових сутностей;
• не змішувати client, customer, counterparty без словника.;

* замовлення створюється з правильними даними; * дублікат не створюється; * порожній SKU дає помилку; * невідомий товар дає помилку; * користувач системи без прав отримує 403; * повторний запит повертає існуюче замовлення; * відповідь містить external_order_id.;== API-first і GraphQL == } !;== API-first у середньому бізнесі == <pre> * назвати підхід API-first, але не писати контракт; * створювати API після готової системи; * не залучати бізнес-середовище; * не описувати помилки; * не робити версіонування; * не враховувати права доступу; * не робити sandbox; * не логувати запити; * не тестувати контракти; * не мати зовнішніх ID; * не мати мапінгу; * не контролювати навантаження; * не документувати зміни.; API-first сприяє зробити ці обміни стабільними й контрольованими.; # Погодили зовнішні ID.; Приклади: Сайт уже має змогу тестувати створення замовлення, не чекаючи повного бекенду.; } "status": "already_exists", == Приклад API для Power BI == * які інформаційні дані йдуть з BAS; * які інформаційні дані йдуть у BAS; * які зовнішні ID використовуються; * які обробки запускають обмін; * які права має користувач системи обміну; * які журнали помилок є собою; * які API потрібні в K2 ERP; * які старі обміни потрібно вимкнути.; "field": "items [0].sku", !;== API-first і AI == [[SQLite]] має змогу використовуватися в API-first архітектурі як локальне або проміжне сховище.; !; } } Пов’язана сторінка: [[Казначейство]] {| class="wikitable" style="width:100%;" * endpoint-и; * методи; * параметри; * схеми даних; * відповіді; * помилки; * авторизацію; * приклади; * версії; * документацію.;== API-first і soft delete == Приклад: Він має містити: * документація; * стабільність; * версіонування; * rate limiting; * sandbox; * API-ключі; * приклади; * супровід; * changelog; * політика deprecated-версій.;<pre> { Приклади:

Пов’язана сторінка: Power BI

Це істотно для:

• мобільний складський облік;
• мобільні продажі та реалізація;
• сервісний інженер;
• кур’єр;
• керівник із погодженнями;
• HR-застосунок;
• Service Desk;
• польовий аудит;
• інвентаризація.; Він має відображати бізнес-операції.; користувач системи питає AI:

API-first — це не тільки технічна тема.; |- | Які ризики?; "external_order_id": "WEB-10425",

{

Sandbox — це тестове середовище API.; | В ERP, CRM, сайтах, мобільних застосунках, банках, WMS, MES, Power BI, AI й інтеграціях.;== API-first і пагінація ==

API-first і грошові значення

• URL endpoint-ів;
• HTTP-методи;
• структуру запиту;
• структуру відповіді;
• коди помилок;
• авторизацію;
• приклади;
• обмеження;
• версію API;
• характеристика полів.; Коли доречний

 }

Етапи:

Хороший API-first:

!;== Що підготувати перед API-first проєктом ==
 required: true

Черги корисні для:

 "failed": 20,

Такий характеристика можна використовувати для документації, генерації клієнтів, тестів і mock-серверів.; # Перевіряє авторизацію.; Відповідь має змогу містити:

Приклад запиту:

[[Категорія:Паралельний запуск ERP]]

{| class="wikitable" style="width:100%;"

* API Gateway;
* API Catalog;
* governance;
* security policy;
* versioning policy;
* monitoring;
* sandbox;
* developer portal;
* SLA;
* інтеграційна команда;
* архітектурний review.; Термін
!; Для сайту API-first означає, що сайт не “лізе в базу ERP напряму”, а функціонує через зрозумілі методи.; Поширені помилки:

Ланцюг:

'''REST API''' — один із найпоширеніших стилів API.; Значення

інтеграційні функціональні можливості:

Swagger часто застосовують, коли потрібно як інтерфейс для перегляду й тестування API.; "status": "created"

Під час переходу з BAS у K2 ERP потрібно завантажити контрагентів.; Ідемпотентність означає, що повторний однаковий запит не створить дублікат.; Відповідь

API: Власник відповідає за:

}

{

"message": "SKU is required"

Що таке API-first простими словами?

Можна робити API для:

• клієнти дублюються;
• замовлення не прив’язуються до правильних контрагентів;
• платежі не закривають борг;
• Power BI показує різні цифри;
• супровід шукає помилки вручну.;== API-first і електронний документообіг ==

API-first і direct database access

Потрібно визначити: Обмін має змогу включати: delivery_address API має бути зрозумілим для розробників і бізнесу.; GET /api/v1/jobs/JOB-2026-0001 У сучасній архітектурі API-first часто поєднується з event-driven підходом.; як ілюстрація:

API-first і BAS

!; Приклад:

},

Типові API:

MES-система потребує API для виробництва.; API-first не забороняє швидку розробку, але змушує домовитися про обмін даними до того, як різні команди зроблять несумісні рішення для бізнесу.; external_order_id = WEB-10425

!; API-first сприяє зробити інтеграції керованими, а не залежними від випадкових файлів і ручних обробок.;== API-first і паралельний запуск ERP ==

Запит: API має змогу дозволяти:

== Приклад валідації замовлення ==
== API-first і ORM ==
Після запуску інтеграції виявилося:
REST добре підходить для ERP, CRM, сайтів, мобільних застосунків і інтеграцій.; Через API можна підключати:

* перевіряє external_order_id;
* повертає вже створене замовлення;
* не дублює товарний резерв.; # Доводиться терміново переробляти обидві сторони.; Кращий підхід:

API має бути проєктований з урахуванням навантаження.; # Виявилося, що в ERP немає зовнішнього ID.; "error_code": "PRODUCT_NOT_FOUND",

<pre>

* сайт;
* інтернет-магазин;
* CRM;
* WMS;
* MES;
* TMS;
* банк;
* Power BI;
* електронний електронний документообіг;
* мобільний застосунок;
* AI-асистента;
* партнерський кабінет;
* сервісний портал;
* міграційні інструменти;
* зовнішні довідники.; Поганий API:
Інакше сайт має змогу продовжити продавати товар, який уже неактивний в ERP.; "status": "accepted"

}

!; GET /api/v1/approvals?assignee=current_user&status=pending
API-first для банку має описувати:

Хороший API має повертати зрозумілі помилки.; "total": 1000,

== Недоліки API-first ==

}
<pre>

• дату;
• клієнта;
• товарну групу;
• суму продажів;
• собівартість;
• маржу;
• менеджера;
• підрозділ;
• канал продажу.; У бекенді API часто функціонує разом з ORM.; * права користувача;
• статус заявки;
• бюджетний ліміт;
• договір;
• контрагента;
• валюту;
• банківський рахунок;
• дублікати;
• закритий період;
• маршрут погодження.;== API-first і міграція даних ==

API-first і CI/CD

totalAmount

API-first і відповідальність

Приклад:

"sku": "USB-C-1M-BLK",

Пов’язана сторінка: Аудит дій

• які бізнес-об’єкти доступні через API;
• які дії можна виконувати;
• які поля передаються;
• які формати даних використовуються;
• які права доступу потрібні;
• які помилки можливі;
• які статуси повертаються;
• як функціонує версіонування;
• як тестується API;
• як API документується;
• як інші системи будуть інтегруватися.;== API-first і DevOps ==

/orders:

У code-first спочатку пишуть код, а API описують пізніше.; !;== Типові помилки API-first ==

API-first надає можливість описати старі інтеграції BAS, створити нові API в K2 ERP, перенести зовнішні ID, протестувати обміни й поступово вимкнути старі обробки.;== Пов’язані сторінки ==

1. Спочатку описали API замовлення.; характеристика

!; Підхід

Це краще, ніж:

охоплює:

API-first і локалізація

{

Контракт має змогу включати:

; !; Перевага Що таке API-first Чому не варто давати інтеграціям прямий доступ до бази? "sku": "USB-C-1M-BLK", Версіонування потрібне, щоб: Безпечні зміни: Банк тимчасово недоступний.; Помилки API мають бути видимими.; Напрям які статуси існують; коли замовлення вважається оплаченим; чи можна змінювати ціну; як функціонує резерв; як визначається замовник; які поля обов’язкові; як обробляються повернення; хто відповідає за помилки.; У контексті K2 ERP API-first означає, що ERP не є собою “закритою коробкою”, а має зрозумілі API-контракти для обміну з сайтом, CRM, банком, складом, виробництвом, Power BI, зовнішніми сервісами, міграційними інструментами і AI-рішеннями.; Якщо без ускладнень змінити API без версії, сайт або CRM можуть зламатися.; "status": "created" максимальний розмір; формати; спосіб завантаження; спосіб отримання; права доступу; строк зберігання; антивірусну перевірку; аудит завантаження.; Статуси мають бути чітко описані.; ] GET /api/v1/analytics/sales?date_from=2026-05-01&date_to=2026-05-31 створення дубльованих замовлень; передача сум без валюти; відсутність договору; відсутність зовнішнього ID; зміна цін без аудиту; прямий доступ до бази; API-користувач із повними правами; невраховані закриті періоди; відсутність контрольних сум; немає перевірки прав по організації або складу.; # Оплата передається окремо.; Фільтри дозволяють отримувати тільки потрібні інформаційні дані.;=== Як API-first сприяє при переході з BAS у K2 ERP? === API-first полегшує підтримку, якщо є собою: Пов’язана сторінка: WMS система "amount": 24500.00, маршрутизацію; авторизацію; rate limiting; логування; трансформацію запитів; перевірку токенів; кешування; моніторинг; захист від атак; централізований аудит.; API-first — це архітектурний і продуктовий підхід, у якому API розглядається як перший рівень проєктування системи.; "external_order_id": "WEB-10425", Приклад webhook дилери створюють замовлення; постачальники оновлюють ціни; логістичні партнери передають статуси; маркетплейси синхронізують товари; сервісні партнери створюють заявки; банки передають статуси платежів.; Потрібні: У мікросервісній архітектурі API-first особливо важливий, бо сервіси взаємодіють між собою через контракти.;== API-first і фінансові інформаційні дані == API-first і формат відповіді як ілюстрація: назву API; характеристика; власника; версію; документацію; статус; середовища; endpoint-и; права доступу; SLA; changelog.;== API-first і сортування == "id": "ERP-000145", кількість знаків після коми; правила округлення; валюту; ПДВ; знижки; суму з податком; суму без податку; ціну рядка; загальну суму; формат у JSON.; Ризик !; } !; # Потім розробили сайт.;== API-first і API == == Приклад ідемпотентності == {| class="wikitable" style="width:100%;" Для API-first істотно мати журнал інтеграцій.; API має враховувати права користувача або сервісу.; Що означає !;== Впровадження API-first == "order_id": "ERP-000145" !; # Статуси не збігаються.; API має відображати бізнес-домен, а не випадкову структуру бази.; Але для основного API великої ERP частіше потрібна серверна СУБД.; Він має змогу виконувати: 2026-05-15T10:30:00Z <pre> [[Категорія:Казначейство]] requestBody: З API-first бізнес-процес інший: <pre> * обробки великих імпортів; * відправки повідомлень; * синхронізації з WMS; * webhook-ів; * повторних спроб; * банківських операцій; * інтеграцій із нестабільними сервісами.; як ілюстрація: * доступ через API; * правила валідації; * права доступу; * аудит; * стабільний контракт; * контроль навантаження.; Сайт !; "message": "SKU is required" '''Contract-first''' означає, що спочатку описують контракт API, а потім пишуть код.; Кожен сервіс має мати зрозумілий API.; } <pre> <pre> customer_phone [[Категорія:Інтеграції]] } |- | Номенклатура | ERP |- | Залишки | ERP або WMS, залежно від процесу |- | Ліди | CRM |- | Платежі | Банк / казначейство |- | Договори | ERP або електронний документообіг |- | аналітичні інструменти | BI-сховище |} API-first має включати безпеку з першого етапу.; Що роблять спочатку API Gateway — це шар, через який проходять API-запити.; Він має змогу містити: Воно потрібне, щоб партнери або команди могли: * стандарти іменування; * правила версіонування; * безпеку; * документацію; * review API-контрактів; * каталог API; * політики доступу; * моніторинг; * бізнес-процес змін; * відповідальних власників.; Приклад: ERP має не створити дублікат, а повернути відповідь: Для грошей потрібно погодити: * створити замовлення; * отримати залишки; * оновити ціну; * створити платіж; * отримати статус документа; * завантажити контрагента; * перевірити кредитний ліміт; * створити сервісну заявку; * отримати інформаційні дані для Power BI; * передати результат виробничої операції; * синхронізувати довідники.; Приклад документації endpoint-а GET /api/v1/orders?status=paid&date_from=2026-05-01&date_to=2026-05-31 API має мати єдиний формат дат.; Хороший API має бути стабільним, документованим, безпечним, версіонованим, тестованим, зрозумілим для бізнесу й технічних команд.; це підхід до розробки програмних систем, у якому API проєктується як ключовий програмний продукт і контракт між системами ще до повної реалізації інтерфейсу, бізнес-логіки або інтеграцій виступає ключовою рисою API-first.; GET /api/v1/products?sort=name Сайт /orders, /stock, /prices Замовлення, залишки, ціни Двосторонній CRM /customers, /invoices Клієнти, рахунки, статуси Двосторонній Банк /payments, /statements Платежі, виписки Двосторонній Power BI /analytics продажі та реалізація, фінансовий блок, складський облік ERP → BI WMS /warehouse Приймання, відвантаження, залишки Двосторонній API-first корисний не тільки для мікросервісів.;== Приклад API-контракту == Пов’язана сторінка: Права доступу в ERP продажів; залишків; платежів; дебіторки; кредиторки; бюджетів; виробництва; Service Desk; користувачів; контрольних сум; довідників.; POST /api/v1/products/bulk API-first і аудит дій Краще: чи валідний OpenAPI-файл; чи не зламався контракт; чи проходять contract tests; чи відповідає реалізація документації; чи немає небезпечних змін; чи оновлено changelog; чи проходять security-тести.; Цей ID має змогу пройти через: "email": "info@example.com" Backward compatibility означає, що нові зміни не ламають старих клієнтів.; delivery_postcode Приклад обмеження API-користувача У REST ресурси представлені через URL.; "external_id": "BAS-T-002", читати зарплату; змінювати договори; проводити платежі; отримувати собівартість; адмініструвати систему.; Метод API-first і backward compatibility responses: == API-first і валюти == API повертає: == API-first і сайт == API-first передбачає методи: Для інтеграцій і міграцій потрібні контрольні суми.; OpenAPI надає можливість описати: * фронтенду розроблятися паралельно; * партнерам тестувати інтеграцію; * бізнесу перевірити формат; * QA писати тести; * швидше виявити проблеми контракту.; { У пайплайні можна автономно перевіряти: Це надає можливість не зупиняти весь імпорт через кілька помилок.; "status": "Оплачено" == Приклад mock API == == API-first і зовнішні ID == == API-first і документація == {| class="wikitable" style="width:100%;" Події допомагають системам реагувати без постійного опитування API.; Це зменшує хаос, дублікати, помилки й переробки.; |- | Що істотно?; "message": "Quantity must be greater than 0" "name": "Кава арабіка 1 кг" GET /customers <pre> [[Категорія:K2 ERP]] Подія: Ознаки технічного боргу в API: == API-first і доменна модель == Банківські інтеграції особливо чутливі до безпеки й контролю.; # Сайт і ERP розробляються паралельно за одним контрактом.; summary: Create order { GET /api/v1/products?page=1&page_size=100 Вона має містити: * створення платіжного доручення; * статус платежу; * завантаження виписки; * залишок рахунку; * валютні операції; * комісії; * помилки; * підписання; * права доступу; * журнал аудиту.; Partner API — це API для зовнішніх партнерів.; Сайт отримує цю подію й показує клієнту статус відправки.; DELETE /drafts/20 == API-first і статуси HTTP == '''GraphQL''' — це підхід, де замовник сам запитує потрібну структуру даних.;<pre> "external_id": "BAS-T-001", {| class="wikitable" style="width:100%;" !; POST /orders "status": "imported" "error": { бо інтеграційні функціональні можливості має змогу автономно зрозуміти, що саме потрібно виправити.; Приклади: "items": [ POST /table_145/insert [[Категорія:Інтеграція з BAS]] !; Приклади: == API-first і governance == [[Категорія:AI]] * створювати замовлення; * читати залишки; * читати ціни; * отримувати статуси.; "external_order_id": "WEB-10425", == API-first і джерело правди == == API-first при впровадженні ERP == "job_id": "JOB-2026-0001", Для Power BI API-first означає, що аналітичні інструменти отримує інформаційні дані через стабільний, контрольований шар.; } Прямий доступ до бази обходить бізнес-логіку, права доступу, аудит і валідацію.; {| class="wikitable" style="width:100%;" PUT /orders/145 ] * кількість запитів; * час відповіді; * кількість помилок; * кількість 4xx; * кількість 5xx; * найповільніші endpoint-и; * rate limit; * використання API-ключів; * кількість повторних спроб; * кількість дублікатів; * статуси інтеграцій.; Метод == API-first і OpenAPI == === Чим API-first відрізняється від code-first? === |- | new | Замовлення створене |- | confirmed | Замовлення підтверджене |- | paid | Оплата отримана |- | reserved | Товар зарезервований |- | shipped | Замовлення відвантажене |- | cancelled | Замовлення скасоване |} === Що таке API-контракт? === == API-first і персональні інформаційні дані == == Приклад retry == * формат дати; * часову зону; * формат дати й часу; * правила зберігання; * правила відображення; * поведінку при переході між часовими зонами.; * систему-джерело; * систему-приймач; * endpoint; * external_id; * request_id; * correlation_id; * статус; * помилку; * час; * повторні спроби; * відповідального.; # Потім згадали про інтеграцію.; GET /api/v1/products/changes?updated_after=2026-05-15T10:00:00Z "quantity": 0 Потрібно: * сайт має змогу створювати замовлення, але не бачить зарплату; * Power BI має змогу читати аналітичні інформаційні дані, але не змінює документи; * WMS має змогу змінювати складські операції, але не фінансовий блок; * AI-асистент бачить тільки дозволені користувачу інформаційні дані; * банк-інтеграція функціонує тільки з платежами.; Інкрементальна синхронізація надає можливість отримувати тільки зміни після певного моменту.; як ілюстрація, при створенні платежу API має перевірити: ERP; CRM; сайт; банк; складський облік; BI; електронний документообіг; Service Desk.; API-first і Service Desk == API-first і public API == <pre> API-first добре поєднується з CI/CD.; Документація API — обов’язкова частина API-first.; {| class="wikitable" style="width:100%;" GET /api/v1/products?cursor=abc123&limit=100 == API-first і статуси == |- | order_id | external_order_id | Зовнішній номер замовлення |- | customer_phone | customer.phone | Пошук клієнта |- | sku | items.sku | Пошук товару |- | delivery_type | delivery.service | Служба доставки |- | paid | payment_status | Статус оплати |} API потрібно моніторити.; "items": [ == API-first і помилки == * швидші інтеграції; * менше переробок; * паралельна розробка програмного забезпечення; * краща документація; * стабільні контракти; * простіше підключати партнерів; * краща безпека; * кращий контроль змін; * простіше тестування; * простіше масштабування; * якісніша аналітичні інструменти; * краща готовність до AI; * простіший перехід з BAS у K2 ERP.;== Приклад bulk API == { Потрібно уніфікувати відповіді.; Після зміни структури таблиць такі інтеграції без зайвих зусиль ламаються.; При заміні BAS API-first сприяє не переносити залежність від старих зовнішніх обробок.;== API-first і бізнес-команди == {| class="wikitable" style="width:100%;" API-first і моноліт Коротко Ризики: API-first і інкрементальна синхронізація Фінансові API мають бути особливо захищені.; | Підхід, коли API проєктують першим як контракт між системами.; "sku": "", Пов’язана сторінка: CRM для продажів прискорити інтеграції; зменшити хаос у даних; скоротити ручні обміни; паралельно розробляти фронтенд і бекенд; спростити мобільні застосунки; підключати партнерів; будувати мікросервіси; створювати зрозумілі контракти; тестувати API до завершення реалізації; зменшити кількість переробок; підготувати ERP до масштабування; полегшити міграцію з BAS або старих систем; підтримувати Power BI, AI, Service Desk і зовнішні сервіси.; "message": "Validation failed", Для ERP особливо небезпечні: хто зробив запит; коли зробив запит; який endpoint викликав; який об’єкт змінив; який external_id використав; який статус відповіді; яка помилка виникла; який IP або сервіс; який correlation_id; хто підтвердив критичну дію.;== Приклад AI + API-first == } API governance — це правила керування API в компанії.; |} API-first і внутрішні команди 503 Service Unavailable API-first і версіонування API Catalog — це каталог усіх API компанії.; POST /service-tickets Приклади сервісів: created_at; updated_at; deleted_at; version; change_id.; { order.shipped Приклад OpenAPI-фрагмента |- | POST /orders | 12 400 | 35 | 180 мс |- | GET /stock | 48 000 | 12 | 95 мс |- | POST /payments | 1 200 | 5 | 220 мс |- | GET /analytics/sales | 320 | 0 | 900 мс |} GET /customers/15 == API-first і дата/час == API потрібно тестувати окремо.; Мапінг описує відповідність полів між системами.; | Відсутність документації, хаотичні endpoint-и, прямий доступ до бази, дублікати, слабка безпека й зламані інтеграції.;== API-first і MES == * рахунками; * актами; * договорами; * PDF; * фото; * сертифікатами; * накладними; * документами доставки; * вкладеннями Service Desk.; Окремо варто відзначити CRM, e-commerce, банківських інтеграцій, WMS, MES, Service Desk, мобільних застосунків, BI, Power BI, AI-асистентів, партнерських кабінетів і мікросервісної архітектури.; Його часто використовують разом зі Swagger.; Потрібні правила іменування.; API-first вирішує це через погоджений мапінг і контракт.; Контроль має змогу включати: == API-first і ідемпотентність == POST /api/v1/customers/import == Типові коди помилок API == } Потрібно логувати: [[Категорія:Power BI]] == API-first і sandbox == Запит: == API-first і карта інтеграцій == { Для критичних операцій використовують idempotency key.; POST /orders "details": [] Текст “Оплачено” можна відобразити в інтерфейсі, але API краще функціонує з кодами.; # Погодили статуси.; API описати бізнес-процеси; визначити системи; зробити карту інтеграцій; визначити джерела правди; описати доменні об’єкти; створити API-контракти; погодити OpenAPI; створити mock API; написати тести; реалізувати backend; підключити frontend і інтеграції; налаштувати безпеку; увімкнути моніторинг; вести changelog.; * API для ERP ERP K2 ERP Інтеграція з BAS Заміна BAS Міграція даних Вивантаження даних CRM для продажів Power BI BI система AI ORM SQLite Service Desk Казначейство ERP для складу WMS система ERP для виробництва MES система ERP для документообігу Права доступу в ERP Аудит дій Паралельний запуск ERP ERP в хмарі Впровадження ERP Запуск ERP POST /stock-transfers } Це корисно для: Довгі операції краще виконувати асинхронно.; # API повертає відповідь.; Mock сприяє: Приклади об’єктів: '201': не ламати старі інтеграції; поступово переводити клієнтів; тестувати нові поля; підтримувати партнерів; контролювати зміни; документувати deprecated-методи.; Події можуть бути: API-first має одразу передбачати зовнішні ID для: API-first і deprecated API платежі; банківські рахунки; залишки коштів; дебіторка; кредиторка; зарплата; собівартість; бюджет; маржа; договори; ліміти.;== API-first і контрольні суми == ; # Валідує інформаційні дані.; # У сайту інший формат товарів.; } Результат — стабільні API, зрозумілі інтеграції, менше ручної роботи, краща безпека, контроль помилок, якісна аналітичні інструменти й готовність ERP до розвитку.; Статус У v2 адресу розділили: API-first корисний при міграції даних.; # Спочатку розробили ERP-модуль замовлень.; Потрібно обмежувати: paths: X-Correlation-ID: 9f7a-2026-05-15-web-10425 API-first особливо важливий для ERP.; !; # ORM читає або записує інформаційні дані.; Малий бізнес-середовище має змогу використовувати API-first для простих задач: Пов’язана сторінка: AI Навіть невеликий API-контракт краще, ніж ручний Excel-обмін без правил.; Для критичних API потрібен SLA.; API-first і технічний борг Запит містить масив товарів: Це потрібно, щоб: API-first потрібен, щоб інтеграції були передбачуваними, документованими, безпечними й стабільними.; # Погодили поля.; AI не читає базу напряму.; Bulk API потрібен для масових операцій.; Idempotency-Key: WEB-10425-create-order Приклад відповіді: "external_order_id": "WEB-10425", * обхід бізнес-логіки; * обхід прав доступу; * немає аудиту; * залежність від структури таблиць; * складні актуалізація; * ризик пошкодження даних; * немає стабільного контракту; * Power BI або інтеграційні функціональні можливості можуть зламатися після зміни схеми.; API має змогу працювати з файлами: { }, Іншими словами, команда спочатку домовляється, як системи будуть обмінюватися даними, які методи доступні, які поля передаються, які помилки можливі, які права потрібні, а вже потім розробляє вебінтерфейс, мобільний застосунок, інтеграції, ERP-модулі або аналітику.;== Приклад API-first в ERP == !;<pre> "name": "Кабель USB-C 1 м" переважні аспекти: == API-first і staging == "external_id": "BAS-CUST-00077", <pre> '''OpenAPI''' — це формат опису REST API.; Сайт Поганий підхід: * доступність; * максимальний час відповіді; * час реакції на помилки; * регламент підтримки; * відповідальних; * допустимі вікна обслуговування; * процедуру аварійного відновлення.; Це особливо істотно для замовлень, платежів, імпорту й webhook-ів.; Підхід !; !; "code": "VALIDATION_ERROR", * ПІБ; * телефони; * email; * адреси; * ІПН; * зарплату; * кадрові інформаційні дані; * банківські реквізити; * історію дій; * документи працівників.; {| class="wikitable" style="width:100%;" Дозволено: Або cursor-based: організації; підрозділи; користувачі; ролі; контрагенти; договори; номенклатура; склади; залишки; замовлення; рахунки; платежі; заявки; виробничі операції; сервісні заявки; документи.; "field": "items [0].quantity", API-first і продуктивність customer(id: 15) { ;== переважні аспекти API-first == "success": 980, створити договір; передати файл; отримати статус підписання; отримати підписаний PDF; перевірити контрагента; передати акт; зв’язати документ із замовленням; нагадати про строк дії.; Try again later." { { Приклад: Підхід сприяє: API-first і SQLite "order_id": "ERP-000145", API змінюється з часом, з цієї причини потрібне версіонування.; !; * потрібен час на проєктування; потрібна дисципліна; потрібна участь бізнесу; потрібні стандарти; потрібно підтримувати документацію; потрібно тестувати контракт; потрібно керувати версіями; API має змогу бути надмірно складним без governance; погано спроєктований API важко змінювати.; { !; * список систем; * список інтеграцій; * бізнес-процеси; * довідники; * статуси; * мапінг полів; * список зовнішніх ID; * вимоги безпеки; * права доступу; * вимоги до продуктивності; * вимоги до аналітики; * сценарії помилок; * приклади запитів; * тестові інформаційні дані; * власників API.; Сценарії: Потрібно врахувати: Якщо замовник повторить той самий запит із тим самим ключем, API не створить дубль.; інформаційні дані API-first і частковий успіх організація впроваджує ERP і хоче інтегрувати її з інтернет-магазином.; * створювати довідники; завантажувати контрагентів; завантажувати номенклатуру; завантажувати договори; завантажувати залишки; передавати відкриті документи; зберігати зовнішні ID; отримувати помилки валідації; звіряти контрольні суми.; HTTP-статуси мають використовуватися послідовно.; "active": false, Для чого потрібен API-first? Потрібно визначити: замовлень; платежів; доставок; імпорту довідників; міграції; webhook-ів; повторних спроб після помилки.; Показник Без API-first часто буває так: як ілюстрація, для замовлення бізнес-середовище має визначити: "sku": "USB-C-1M-BLK", GET /stock/tasks Отримати задача комірника POST /stock/scan Передати сканування штрихкоду POST /stock/move Оформити переміщення POST /stock/inventory Передати результат інвентаризації GET /products/{barcode} Знайти товар за штрихкодом організація хоче, щоб мобільний застосунок складу працював з ERP.;=== Що таке OpenAPI? === Карта інтеграцій описує, хто з ким обмінюється даними.; # API отримує запит.; Заборонено: API має змогу дозволяти: api_site Якщо об’єкт видалений або деактивований, API має передавати це зовнішнім системам.; # Викликає бізнес-сервіс.; Джерело правди	; description: Validation error нові версії API; інтеграції; продуктивність; міграції; права доступу; webhook-и; моніторинг; логування; сумісність із клієнтами.; |-	Де застосовується?; [[Категорія:OpenAPI]] == Простий приклад API-first == [[Категорія:ERP]] orders { == Типові помилки в ERP API == "items": [ POST /api/v1/orders Приклад: API має змогу передавати персональні інформаційні дані, з цієї причини потрібен контроль.; як ілюстрація: } == API-first і мобільні застосунки == * отримати каталог; * отримати ціни; * отримати залишки; * створити замовлення; * передати оплату; * отримати статус; * створити повернення; * отримати номер ТТН; * оновити клієнта.; Потрібно продумати: == API-first і тестування == Рекомендовано одразу погодити: { <pre> Приклад успіху: API-ключі, токени й секрети не можна зберігати в коді або відкритих файлах.; Краще не передавати суму без валюти, особливо якщо платформа функціонує з UAH, USD, EUR або іншими валютами.;=== Який результат правильного API-first підходу? === У великому бізнесі API-first стає частиною корпоративної архітектури.; Приклад: { {| class="wikitable" style="width:100%;" Service Desk має змогу використовувати API для інтеграції із ERP, CRM, поштою, Telegram-ботом або порталом користувача.; Призначення Error 500 === Чому API-first важливий для ERP? === "customer": { * авторизацію; * автентифікацію; * ролі; * права доступу; * API-ключі; * OAuth; * JWT; * IP-обмеження; * rate limiting; * аудит; * шифрування; * логування; * захист персональних даних; * захист фінансових даних.; захистити API від перевантаження; запобігти помилкам інтеграцій; контролювати партнерів; зменшити ризик атак; стабілізувати систему.; * описати старі інтеграції BAS; знайти зовнішні обробки; знайти API або файли обміну; описати зовнішні ID; створити нові API в K2 ERP; протестувати обмін; перенести Power BI; вимкнути старі інтеграції після запуску.; Power BI; WMS; мобільних застосунків; кешів; інтеграцій; міграційних перевірок.; * інтегрованою; модульною; готовою до мобільності; готовою до AI; готовою до Power BI; готовою до партнерських сервісів; готовою до хмарної архітектури; готовою до швидких змін бізнесу.; переважні аспекти: API-first і логування помилок	; DevOps у API-first відповідає за:
GET	/api/v1/products	Отримати список товарів
GET	/api/v1/products/{sku}	Отримати товар за артикулом
POST	/api/v1/orders	Створити замовлення
GET	/api/v1/orders/{id}	Отримати замовлення
PATCH	/api/v1/orders/{id}/status	Оновити статус
GET	/api/v1/stock	Отримати залишки

!;== API-first і мапінг даних ==

API-first і права доступу

Rate limiting обмежує кількість запитів за певний час.; * бізнес-логіку;

• контракт;
• документацію;
• версіонування;
• помилки;
• підтримку;
• SLA;
• зміни;
• безпеку;
• відповідність процесу.;

API-first і події

• додати необов’язкове поле;
• додати новий endpoint;
• додати новий статус із документацією;
• розширити відповідь без видалення старих полів.; "event": "order.shipped",

Чим API-first відрізняється від code-first

number

• order.created;
• order.paid;
• order.shipped;
• payment.received;
• invoice.created;
• stock.changed;
• customer.updated;
• contract.expired;
• approval.completed;
• ticket.created.; API ERP

|- | REST | Простий і зрозумілий | ERP-інтеграції, CRUD, стандартні обміни |- | GraphQL | Гнучкий вибір полів | Складні фронтенди, багато різних клієнтів |- | Webhooks | Події в реальному часі | Статуси, сповіщення, інтеграції |- | Batch API | Масова передача | Міграція, синхронізація, великі довідники |}

API-first і retry-логіка

"active": true

"sku": "COFFEE-1KG",

• замовлення підтверджено;
• товар відвантажено;
• платіж отримано;
• статус доставки змінено;
• замовник заблокований;
• залишок змінився;
• документ погоджено.; Небезпечні зміни:

"payment_status": "paid",

"error_code": "SKU_EMPTY",

!; Напрям

Якщо джерело правди не визначене, системи починають перезаписувати одна одну.; Щоб API був зрозумілий, потрібен єдиний словник.; Навіть монолітна ERP має змогу мати API.;== Приклад зміни версії API ==

Команда ERP створила поле:

Mock API — це імітація API, яка функціонує ще до готової реалізації.; OpenAPI — це формат опису REST API, який надає можливість документувати endpoint-и, параметри, схеми даних, відповіді, помилки й авторизацію.; |- | Який результат?; !; |- | ERP → сайт | Товари | GET /products |- | ERP → сайт | Залишки | GET /stock |- | ERP → сайт | Ціни | GET /prices |- | Сайт → ERP | Замовлення | POST /orders |- | Сайт → ERP | Оплата | POST /payments |- | ERP → сайт | Статус | Webhook order.status_changed |}

"external_id": "BAS-CUST-00077",

== API-first і валідація ==

* CRM створює ліда;
* CRM передає клієнта в ERP;
* ERP повертає рахунок;
* ERP повертає статус оплати;
* ERP повертає дебіторку;
* CRM показує менеджеру статус відвантаження;
* ERP отримує прогноз продажів із CRM.; Відповідь:

Сортування має бути передбачене контрактом.; {
<pre>
!; Недоліки або складності:

== REST чи GraphQL ==
}

Зовнішній ID — це ідентифікатор об’єкта в іншій системі.; API краще передавати стабільні коди, а не локалізовані тексти.; * endpoint;

• метод;
• тіло запиту або безпечний фрагмент;
• код відповіді;
• error_code;
• користувача;
• external_id;
• correlation_id;
• час;
• IP;
• повторну спробу;
• результат.; API

• немає документації;
• endpoint-и названі хаотично;
• немає версій;
• помилки незрозумілі;
• немає зовнішніх ID;
• немає тестів;
• немає власника;
• API змінюється без попередження;
• інтеграції мають повні права;
• партнери отримують різні формати;
• Power BI читає інформаційні дані напряму з бази.; Код

Приклад статусів замовлення:

"quantity": 2,

]

Приклад:

[[Категорія:WMS]]
У staging перевіряють:
Пов’язана сторінка: [[API для ERP]]
 "errors": [
== Приклад REST API для ERP ==
== API-first і Power BI ==
Пов’язана сторінка: [[Інтеграція з BAS]]

!; API-контракт — це характеристика endpoint-ів, методів, полів, форматів, відповідей, помилок, авторизації, статусів і прикладів використання API.; {

'''Джерело правди''' — це платформа, яка є собою головною для певних даних.; {

Журнал має містити:

* мобільних застосунків;
* BI;
* інтеграцій;
* мікросервісів;
* AI;
* автоматизації;
* Service Desk;
* розробки нових модулів.; delivery_street
== API-first і файли ==
 "customer_id": "K2-CUST-00991",
</div>
<pre>

<pre>

 "shipped_at": "2026-05-15T10:30:00"

"external_id": "BAS-T-077",

• бачити список методів;
• читати характеристика полів;
• тестувати запити;
• переглядати приклади;
• перевіряти відповіді;
• показувати API партнерам;
• швидше онбордити розробників.;== Для чого потрібен API-first ==

• документація;
• приклади;
• журнал змін;
• sandbox;
• тестові ключі;
• зрозумілі помилки;
• Service Desk;
• SLA;
• контакт технічної підтримки;
• статус-сторінка;
• контроль версій.;== Приклад міграції через API ==

• локальний агент синхронізації;
• кеш API;
• черга запитів;
• журнал інтеграцій;
• тестове середовище;
• mock API;
• міграційна база.;== API-first і асинхронні задачі ==

},

• contract tests;
• unit tests;
• integration tests;
• security tests;
• performance tests;
• regression tests;
• negative tests;
• load tests;
• end-to-end tests.; В API-first спочатку погоджують контракт API, поля, помилки, версії та правила обміну.;== API-first і webhooks ==

Для фінансових API потрібно чітко описувати валюту й суму.; | Керована цифрова технічна архітектура, стабільні обміни, швидші інтеграції й готовність до K2 ERP, BI та AI.;== FAQ ==

як ілюстрація, імпорт 100 000 товарів.; Під час паралельного запуску ERP API-first сприяє контролювати обмін між старою і новою системою.; * використовувати secret manager;

• обмежувати доступ;
• регулярно ротувати ключі;
• не логувати токени;
• розділяти ключі для середовищ;
• відкликати старі ключі;
• контролювати сервісні облікові записи.;

"error_code": "RATE_LIMIT_EXCEEDED",

Для інкрементального обміну об’єкти мають мати поля: |- | Що таке API-first?; "status": "paid"

Відповідь має показати, які записи успішні, а які з помилками.;== Приклад моніторингу API ==

Сайт відправив замовлення, але не отримав відповідь через збій мережі.; Головне. API-first — це підхід, коли інтеграції не додаються “потім якось прикрутимо”, а проєктуються одразу: з описом методів, форматів, статусів, помилок, прав доступу, версій, обмежень і прикладів запитів.;

Приклади:

користувач системи:

API-first і мікросервіси

} Потрібна пагінація.; Поле

• мобільний застосунок;
• сайт;
• CRM;
• WMS;
• Power BI;
• партнери;
• AI;
• міграційні інструменти;
• інтеграції без прямого доступу до бази.; | Endpoint-и, поля, формати, відповіді, помилки, авторизацію, версії, статуси й приклади.; Він відправляє замовлення ще раз.; client_id

істотно, щоб API не був без ускладнень “обгорткою над таблицями”.; }

 "data": {
API-first не означає відкривати базу даних напряму.; '''істотно.''' API-first не означає “зробити багато endpoint-ів”.; Приклади:
== API-first і секрети ==
|-
| Code-first
| Спочатку пишуть код, потім описують API
| API має змогу вийти випадковим і незручним
|-
| API-first
| Спочатку описують API-контракт
| Потрібна дисципліна проєктування
|-
| Integration-last
| Інтеграції роблять наприкінці
| Високий ризик переробок
|-
| Contract-first
| Спочатку погоджують контракт
| Потрібна участь усіх сторін
|}

== API-first і майбутнє ERP ==

завдяки наявності API-first користувачі можуть синхронізувати CRM та ERP.; {| class="wikitable" style="width:100%;"

API-first — це підхід, коли спочатку проєктують API як контракт між системами, а вже потім реалізують код, інтерфейси, інтеграції та бізнес-логіку.; Staging — це середовище, максимально схоже на production.; платформа
Етапи:
{

Ще до готової ERP-логіки mock повертає відповідь:

 }

 }
[[Категорія:Впровадження ERP]]
як ілюстрація:
contact_external_id
|-
| 400
| Некоректний запит
| Не заповнене обов’язкове поле
|-
| 401
| Не авторизований
| Немає токена
|-
| 403
| Заборонено
| Немає прав на документ
|-
| 404
| Не знайдено
| Немає товару з таким SKU
|-
| 409
| Конфлікт
| Замовлення вже існує
|-
| 422
| Помилка валідації
| Сума має бути більшою за 0
|-
| 429
| Забагато запитів
| Перевищено ліміт
|-
| 500
| Внутрішня помилка
| Непередбачена помилка сервера
|}

[[Категорія:API для ERP]]

== API-first і partner API ==

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">

* обов’язковий зовнішній ID;
* кількість більша за 0;
* ціна не від’ємна;
* валюта з довідника;
* замовник має телефон або ЄДРПОУ;
* SKU існує;
* договір активний;
* дата не в закритому періоді;
* користувач системи має право на дію.; Що означає
API має логувати важливі дії.; Потім замовник перевіряє статус:

* 200 — успішне читання;
* 201 — створено;
* 202 — прийнято в обробку;
* 204 — успішно без тіла відповіді;
* 400 — помилка запиту;
* 401 — не авторизовано;
* 403 — заборонено;
* 404 — не знайдено;
* 409 — конфлікт;
* 422 — помилка валідації;
* 500 — помилка сервера.; ERP-системи все більше стають платформами, а не окремими закритими програмами.;== API-first і заміна BAS ==

як ілюстрація, ERP має змогу надіслати повідомлення сайту:

<pre>

* дозволені документи;
* інформаційні дані по ролі користувача;
* аналітичні показники;
* регламенти;
* статуси задач;
* заявки;
* історію клієнта;
* залишки;
* платежі;
* договори.; '400':

'''Correlation ID''' — це ідентифікатор запиту або процесу, який сприяє відстежити ланцюг подій у різних системах.; Відповідь:

== API-first і ERP ==

* які інформаційні дані ще йдуть у стару систему;
* які інформаційні дані вже йдуть у K2 ERP;
* які API використовуються;
* які інтеграції дублюються;
* як рахуються контрольні суми;
* коли вимикаються старі обміни;
* хто відповідає за розбіжності.; | Для стабільних інтеграцій, паралельної розробки, документації, безпеки й меншої кількості переробок.;<pre>

* сайт → ERP;
* CRM → ERP;
* банк → обліковий облік;
* Power BI → звіти;
* мобільний застосунок → складський облік;
* Telegram-бот → заявки.; "name": "ТОВ замовник Плюс",

[[Категорія:Міграція даних]]

 "price": 180.00

* описати всі системи;
* зробити карту інтеграцій;
* визначити джерела правди;
* описати API-контракти;
* погодити статуси;
* погодити довідники;
* визначити зовнішні ID;
* створити mock API;
* написати тести;
* налаштувати безпеку;
* запустити sandbox;
* провести інтеграційне тестування;
* увімкнути моніторинг.;== API-first і SLA ==

"field": "items [0].sku"

API-first і супровід

WMS-система потребує API для складу.;

Які заявки на оплату потрібно погодити сьогодні?; Endpoint

• створює два замовлення.; Під час заміни BAS або інтеграції з BAS API-first сприяє не переносити старий хаос у нову систему.;== Приклад контрольних сум API ==

Мінус має змогу означати сортування за спаданням.; # Погодили правила дублювання.;== API-first і changed_at ==

• frontend чекає контракт, а не готовий backend;
• backend реалізує контракт;
• QA пише тести по контракту;
• DevOps налаштовує gateway і моніторинг;
• бізнес-середовище погоджує поля й статуси;
• партнери отримують документацію;
• аналітики знають джерела даних.; Endpoint

|- | Endpoint | POST /api/v1/orders |- | Призначення | Створення замовлення клієнта |- | Авторизація | Bearer token |- | Обов’язкові поля | external_order_id, customer, items |- | Успішна відповідь | 201 Created |- | Типові помилки | PRODUCT_NOT_FOUND, DUPLICATE_ORDER, VALIDATION_ERROR |}

Метрики:

API — це інтерфейс, через який одна платформа взаємодіє з іншою.; інформаційні дані До розробки мобільного застосунку й ERP-модуля команди погоджують ці методи.;== API-first і bulk API ==

API-first і Swagger

• створити заявку;
• змінити статус;
• призначити відповідального;
• додати коментар;
• прикріпити файл;
• отримати SLA;
• знайти схожі заявки;
• передати інцидент у ERP;
• отримати інформаційні дані користувача.; * сайт;
• API Gateway;
• ERP;
• банк;
• WMS;
• журнал інтеграції;
• Service Desk.; Потрібно повідомити:

"error_code": "VALIDATION_ERROR",

API-first і idempotency key

* виробничі замовлення;
* специфікації;
* операції;
* робочі центри;
* матеріали;
* випуск;
* брак;
* простої;
* фактичні витрати;
* статуси виробництва.; Якщо сайт двічі передасть одне замовлення:

Під час впровадження ERP API-first потрібно включити в план проєкту.; А не:

== Приклад зовнішнього ID ==

* кількість замовлень;
* суму замовлень;
* кількість оплат;
* суму оплат;
* кількість товарів;
* залишки;
* кількість помилок;
* кількість зовнішніх ID;
* кількість дублів;
* кількість успішних webhook-ів.; |-
| Для чого потрібен?; Для документообігу API-first важливий при роботі з договорами, актами, рахунками й підписами.; Payload:

'''Webhook''' — це спосіб повідомити іншу систему про подію.; Приклад:
== API-first і contract-first ==
== API-first і API Catalog ==
== Приклад тестів API ==
[[Категорія:Мікросервіси]]
Internal API застосовується всередині компанії.; Потрібно визначити:
ERP часто інтегрується із сайтом, CRM, банком, WMS, MES, Power BI, AI і зовнішніми сервісами.;== API-first і correlation ID ==

При bulk-операціях істотно підтримувати частковий успіх.;== API-first і моніторинг ==

У v1 замовлення має поле:

Deprecated означає, що метод застарів, але ще тимчасово функціонує.; POST /payment-requests

== API-first і безпека ==
 "delivery_service": "courier"
 "name": "ТОВ Постачальник",
GraphQL має змогу бути корисним, коли різним клієнтам потрібні різні набори полів.;== API-first і CRM ==
API-first надає можливість розробити мобільний застосунок незалежно від основного вебінтерфейсу ERP.;

Команда CRM використовує:

API-first і API Gateway

}

Для POST /orders потрібно перевірити:

Тіло запиту:

API-first у малому бізнесі

API повертає тільки ті заявки, які користувач системи має право бачити.; ERP Пов’язана сторінка: Міграція даних API не має повертати мільйони записів одним запитом.; API-first надає можливість ERP бути:

"status": "created"

"message": "Too many requests.; GET /api/v1/orders?sort=-created_at

Практичний приклад. Якщо інтернет-магазин має створювати замовлення в ERP, API-first означає, що ще до розробки інтеграції погоджують контракт: POST /orders, поля клієнта, товари, ціни, знижки, оплату, доставку, зовнішній ID, можливі помилки й відповідь ERP.; |- | Що описує API-контракт?; Приклади валідації:

Пов’язана сторінка: ERP для документообігу

!; |-
| Замовлення за день
| 240
| 240
| Збігається
|-
| Сума оплат
| 780 000 грн
| 780 000 грн
| Збігається
|-
| Дублі зовнішніх ID
| 0
| 0
| Збігається
|-
| Помилки інтеграції
| 12
| 12
| Потрібне виправлення
|}

API-first зменшує технічний борг, але тільки якщо його дотримуються.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

'''Ідемпотентність''' означає, що повторний однаковий запит не створює небажаних дублювань.; Обмін має змогу включати:

== API-first і changelog ==

 ],

Інтеграції мають вміти повторювати запити.;

Приклад:

• середовища;
• gateway;
• деплой;
• секрети;
• моніторинг;
• логування;
• CI/CD;
• сертифікати;
• rate limiting;
• масштабування;
• резервування;
• аварійне відновлення.; Помилок

* який endpoint застарів;
* чим його замінити;
* до якої дати він працюватиме;
* як перейти на нову версію;
* які ризики залишитися на старій версії.; # Погодили помилки.; {
!;<pre>
Приклади чутливих даних:

Пов’язана сторінка: [[Заміна BAS]]

Без цих полів інтеграції часто змушені щоразу забирати всі інформаційні дані.; {
}
query {

Це краще, ніж вивантажувати всі замовлення й фільтрувати на стороні клієнта.; description: Order created

=== Що таке ідемпотентність API? ===

• тестувати інтеграцію;
• створювати тестові замовлення;
• перевіряти помилки;
• тестувати авторизацію;
• перевіряти webhook-и;
• не псувати бойові інформаційні дані;
• готувати запуск.; Swagger сприяє:

 "type": "supplier",

"tracking_number": "TTN-123456789",

API-first і WMS

Типи тестів: API-first часто пов’язаний із підходом contract-first.; } Впровадження API-first можна робити поетапно.; Changelog потрібен, щоб команди бачили зміни API.; Він звертається до API:

API-first і naming conventions

!;== API-first і словник термінів ==
}

}

== API-first і фільтри ==

• характеристика endpoint-ів;
• приклади запитів;
• приклади відповідей;
• коди помилок;
• правила авторизації;
• ліміти;
• версії;
• статуси;
• поля;
• типи даних;
• сценарії використання;
• changelog;
• контакт підтримки.;

!; Приклад API має перевіряти інформаційні дані до збереження.; Середній час

{{SEO
 

В ERP API-first означає, що ключові бізнес-об’єкти доступні через стабільні API.; API має враховувати бізнес-правила.; Запитів за день