API-first
{
responses:
Практичний приклад. Якщо інтернет-магазин має створювати замовлення в ERP, API-first означає, що ще до розробки інтеграції погоджують контракт: POST /orders, поля клієнта, товари, ціни, знижки, оплату, доставку, зовнішній ID, можливі помилки й відповідь ERP. |-
| 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
| Отримати залишки
|}
Мапінг описує відповідність полів між системами. Такий SEO-опис можна використовувати для документації, генерації клієнтів, тестів і mock-серверів.
Або cursor-based:
Для чого потрібен API-first?
"data": {
/api/v2/orders API-first не забороняє швидку розробку, але змушує домовитися про обмін даними до того, як різні команди зроблять несумісні рішення для бізнесу. Якщо без зусиль змінити API без версії, сайт або CRM можуть зламатися. ! Для фінансових API потрібно чітко описувати валюту й суму. API-first оптимізує зробити ці обміни стабільними й контрольованими. Під час впровадження ERP API-first потрібно включити в план проєкту. користувач системи:
API-first і webhooks
Приклад зміни версії API
! Відповідь:
Кожен сервіс має мати зрозумілий API. Фінансові API мають бути особливо захищені. Це особливо критично для замовлень, платежів, імпорту й webhook-ів. Endpoint
- частоту запитів;
- обсяг даних;
- кешування;
- індекси;
- пагінацію;
- batch-операції;
- асинхронні задачі;
- черги;
- таймаути;
- retry-логіку;
- rate limiting.
'''OpenAPI''' — це формат опису REST API. Його часто використовують разом зі Swagger.== FAQ == містить: GET /api/v1/jobs/JOB-2026-0001 * бачити список методів; * читати SEO-опис полів; * тестувати запити; * переглядати приклади; * перевіряти відповіді; * показувати API партнерам; * швидше онбордити розробників. # Потім розробили сайт. { } "name": "Кабель USB-C 1 м" ] ! "order_id": "MOCK-000001", * організації; * підрозділи; * користувачі; * ролі; * контрагенти; * договори; * номенклатура; * склади; * залишки; * замовлення; * рахунки; * платежі; * заявки; * виробничі операції; * сервісні заявки; * документи. { <pre> * систему-джерело; * систему-приймач; * endpoint; * external_id; * request_id; * correlation_id; * статус; * помилку; * час; * повторні спроби; * відповідального. "status": "accepted" Bulk API потрібен для масових операцій. "phone": "+380XXXXXXXXX", == API-first і BAS == !== Приклад міграції через API == '''API Gateway''' — це шар, через який проходять API-запити. ! ERP == API-first і partner API == Прямий доступ до бази обходить бізнес-логіку, права доступу, аудит і валідацію.== API-first у середньому бізнесі == "error_code": "VALIDATION_ERROR", * замовлень; * платежів; * доставок; * імпорту довідників; * міграції; * webhook-ів; * повторних спроб після помилки. У REST ресурси представлені через URL. API ERP ! * створює два замовлення. # Перевіряє авторизацію. Підхід Через API можна:
Приклад помилки: Ще до готової ERP-логіки mock повертає відповідь:
"status": "created"
description: Order created
API-first і staging
! * кількість запитів;
- час відповіді;
- кількість помилок;
- кількість 4xx;
- кількість 5xx;
- найповільніші endpoint-и;
- rate limit;
- використання API-ключів;
- кількість повторних спроб;
- кількість дублікатів;
- статуси інтеграцій. ERP часто інтегрується із сайтом, CRM, банком, WMS, MES, Power BI, AI і зовнішніми сервісами. Для ERP особливо небезпечні:
- максимальний розмір;
- формати;
- спосіб завантаження;
- спосіб отримання;
- права доступу;
- строк зберігання;
- антивірусну перевірку;
- аудит завантаження. Приклад
REST API — один із найпоширеніших стилів API. API повертає:
"order_id": "ERP-000145",
Приклад відповіді:
API-first — це не тільки технічна тема.== Приклад mock API ==
* рахунками; * актами; * договорами; * PDF; * фото; * сертифікатами; * накладними; * документами доставки; * вкладеннями Service Desk. Можна робити API для: Він здатна містити: PUT /orders/145 Фільтри дозволяють отримувати тільки потрібні інформаційні дані. Приклади:
Сортування має бути передбачене контрактом. |- | Що критично? "external_order_id": "WEB-10425",
totalAmount
{
* мобільний застосунок;
* сайт;
* CRM;
* WMS;
* Power BI;
* партнери;
* AI;
* міграційні інструменти;
* інтеграції без прямого доступу до бази. '400':
}
Потрібно описати:
"failed": 20,
! }
Пов’язана сторінка: [[Аудит дій]]
GraphQL здатна бути корисним, коли різним клієнтам потрібні різні набори полів. # Доводиться терміново переробляти обидві сторони.
Типові помилки API-first
Якщо об’єкт видалений або деактивований, API має передавати це зовнішнім системам. API-first вирішує це через погоджений мапінг і контракт.== API-first і інтеграційні журнали ==
== Приклад AI + API-first == * прискорити інтеграції; * зменшити хаос у даних; * скоротити ручні обміни; * паралельно розробляти фронтенд і бекенд; * спростити мобільні застосунки; * підключати партнерів; * будувати мікросервіси; * створювати зрозумілі контракти; * тестувати API до завершення реалізації; * зменшити кількість переробок; * підготувати ERP до масштабування; * полегшити міграцію з BAS або старих систем; * підтримувати Power BI, AI, Service Desk і зовнішні сервіси. Він має відображати бізнес-операції. ], Це краще, ніж вивантажувати всі замовлення й фільтрувати на стороні клієнта. Приклади: API має бути зрозумілим для розробників і бізнесу.== API-first і REST == * Power BI; * WMS; * мобільних застосунків; * кешів; * інтеграцій; * міграційних перевірок. "external_id": "BAS-T-001", === Чому не варто давати інтеграціям прямий доступ до бази? === Команда CRM використовує: Текст “Оплачено” можна відобразити в інтерфейсі, але API краще функціонує з кодами.[[Категорія:Мікросервіси]] == Приклад обмеження API-користувача == * назвати підхід API-first, але не писати контракт; * створювати API після готової системи; * не залучати бізнес-середовище; * не описувати помилки; * не робити версіонування; * не враховувати права доступу; * не робити sandbox; * не логувати запити; * не тестувати контракти; * не мати зовнішніх ID; * не мати мапінгу; * не контролювати навантаження; * не документувати зміни. # Валідує інформаційні дані. * документація; * приклади; * журнал змін; * sandbox; * тестові ключі; * зрозумілі помилки; * Service Desk; * SLA; * контакт технічної підтримки; * статус-сторінка; * контроль версій. Значення === Що таке API-контракт? === ! POST /service-tickets Інтеграції мають вміти повторювати запити.== API-first і продуктивність == "delivery_service": "courier" == API-first і карта інтеграцій == '''Головне.''' API-first — це підхід, коли інтеграції не додаються “потім якось прикрутимо”, а проєктуються одразу: з описом методів, форматів, статусів, помилок, прав доступу, версій, обмежень і прикладів запитів.== API-first і секрети == * швидші інтеграції; * менше переробок; * паралельна розробка програмного забезпечення; * краща документація; * стабільні контракти; * простіше підключати партнерів; * краща безпека; * кращий контроль змін; * простіше тестування; * простіше масштабування; * якісніша аналітичні інструменти; * краща готовність до AI; * простіший перехід з BAS у K2 ERP. ![[Категорія:Заміна BAS]] API потрібно тестувати окремо. * contract tests; * unit tests; * integration tests; * security tests; * performance tests; * regression tests; * negative tests; * load tests; * end-to-end tests. З API-first бізнес-процес інший: == API-first і сайт == Журнал має містити: * створити замовлення; * отримати залишки; * оновити ціну; * створити платіж; * отримати статус документа; * завантажити контрагента; * перевірити кредитний ліміт; * створити сервісну заявку; * отримати інформаційні дані для Power BI; * передати результат виробничої операції; * синхронізувати довідники. ! Питання <pre> Для кожного API потрібен власник.== API-first і банк == ! API має мати єдиний формат дат.== API-first і correlation ID == Мобільний застосунок майже завжди потребує API.== Чим API-first відрізняється від code-first == # Спочатку розробили ERP-модуль замовлень. Обмін здатна включати: * [[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]] == API-first і internal API == як приклад, імпорт 100 000 товарів.<pre> === Чому API-first важливий для ERP? === client_id == API-first і retry-логіка == * API Gateway; * API Catalog; * governance; * security policy; * versioning policy; * monitoring; * sandbox; * developer portal; * SLA; * інтеграційна команда; * архітектурний review.== API-first і WMS == == API-first і Power BI == </div> * авторизацію; * автентифікацію; * ролі; * права доступу; * API-ключі; * OAuth; * JWT; * IP-обмеження; * rate limiting; * аудит; * шифрування; * логування; * захист персональних даних; * захист фінансових даних. |- | Що описує API-контракт? * дозволені документи; * інформаційні дані по ролі користувача; * аналітичні показники; * регламенти; * статуси задач; * заявки; * історію клієнта; * залишки; * платежі; * договори. Пов’язана сторінка: [[Service Desk]]
як приклад:
"quantity": 0
<pre> "name": "ТОВ клієнт ERP Плюс", "status": "created"
API-ключі, токени й секрети не можна зберігати в коді або відкритих файлах. API ! Навіть монолітна ERP здатна мати API. |- | Для чого потрібен? Призначення
name
- endpoint-и в множині: /orders, /customers;
- поля в snake_case або camelCase;
- статуси в нижньому регістрі;
- коди помилок у верхньому регістрі;
- однакові назви для однакових сутностей;
- не змішувати client, customer, counterparty без словника. API має перевіряти інформаційні дані до збереження. | Відсутність документації, хаотичні endpoint-и, прямий доступ до бази, дублікати, слабка безпека й зламані інтеграції. Воно потрібне, щоб партнери або команди могли:
Приклад:
"message": "SKU is required"
|- | Customer | клієнт ERP або контрагент |- | Order | Замовлення клієнта |- | Invoice | Рахунок на оплату |- | Payment | Оплата |- | Shipment | Відвантаження |- | SKU | Артикул товару |- | External ID | Ідентифікатор у зовнішній системі |}
Він здатна виконувати:
Погано:
Банк тимчасово недоступний. API
"shipped_at": "2026-05-15T10:30:00"
REST чи GraphQL
{
"errors": [
Версіонування потрібне, щоб:
Цей ID здатна пройти через:
Типові коди помилок API
API-first і changelog
WMS-система потребує API для складу.
{{SEO
|title=API-first — підхід до розробки API, ERP, CRM, інтеграцій, K2 ERP і цифрової архітектури
|description=API-first: що це таке, як працює підхід API-first, чим відрізняється від code-first і integration-last, як проєктувати API, OpenAPI, REST, GraphQL, webhooks, версіонування, безпека, приклади для ERP, CRM, сайту, банку, Power BI, BAS, K2 ERP, інтеграцій і міграції даних.
|keywords=API-first, API first, API-first підхід, API для ERP, REST API, OpenAPI, Swagger, GraphQL, webhooks, інтеграції ERP, K2 ERP, API архітектура, мікросервіси, інтеграція з BAS
}}
API-first — це підхід, коли спочатку проєктують API як контракт між системами, а вже потім реалізують код, інтерфейси, інтеграції та бізнес-логіку.== API-first і public API ==
"errors": [
API Catalog — це каталог усіх API компанії. як приклад:
[[Категорія:API]]
* маршрутизацію;
* авторизацію;
* rate limiting;
* логування;
* трансформацію запитів;
* перевірку токенів;
* кешування;
* моніторинг;
* захист від атак;
* централізований аудит. {
{| class="wikitable" style="width:100%;"
GET /api/v1/approvals?assignee=current_user&status=pending
! "job_id": "JOB-2026-0001",
У staging перевіряють:
API:
* мобільних застосунків;
* BI;
* інтеграцій;
* мікросервісів;
* AI;
* автоматизації;
* Service Desk;
* розробки нових модулів. Якщо сайт двічі передасть одне замовлення:
* продажів;
* залишків;
* платежів;
* дебіторки;
* кредиторки;
* бюджетів;
* виробництва;
* Service Desk;
* користувачів;
* контрольних сум;
* довідників. customer_phone
</div>
"external_id": "BAS-T-002",
== API-first і фінансові інформаційні дані ==
== конкурентні переваги API-first ==
== Приклад документації endpoint-а ==
== API-first і формат відповіді ==
Потрібно визначити:
! "name": "Кава арабіка 1 кг"
Небезпечні зміни:
бо інтеграційні функції ERP здатна автоматизовано зрозуміти, що саме потрібно виправити. Що роблять спочатку
"amount": 24500.00,
<pre>
== Для чого потрібен API-first ==
}
},
"order_id": "ERP-000145"
API змінюється з часом, тому потрібне версіонування. Ідемпотентність означає, що повторний однаковий запит не створить дублікат. Перевага
* order.created;
* order.paid;
* order.shipped;
* payment.received;
* invoice.created;
* stock.changed;
* customer.updated;
* contract.expired;
* approval.completed;
* ticket.created. Середній бізнес-середовище зазвичай має кілька систем:
'''GraphQL''' — це підхід, де клієнт ERP сам запитує потрібну структуру даних. Це критично для:
! Сайт
== API-first і MES ==
{| class="wikitable" style="width:100%;"
|-
| POST /orders
| 12 400
| 35
| 180 мс
|-
| GET /stock
| 48 000
| 12
| 95 мс
|-
| POST /payments
| 1 200
| 5
| 220 мс
|-
| GET /analytics/sales
| 320
| 0
| 900 мс
|}
== Приклад контрольних сум API ==
Краще не передавати суму без валюти, особливо якщо платформа функціонує з UAH, USD, EUR або іншими валютами. Mock оптимізує:
Подія:
Метрики:
== API-first і сортування ==
delivery_postcode
API-first у великому бізнесі
Потрібно уніфікувати відповіді.== API-first і дата/час == Payload:
Але для основного API великої ERP частіше потрібна серверна СУБД. Це краще, ніж:
API-first і Service Desk
API-first і soft delete
Пов’язана сторінка: Заміна BAS
API-first і ідемпотентність
! Потрібно врахувати: Етапи: Навіть невеликий API-контракт краще, ніж ручний Excel-обмін без правил. Потрібно:
Типові помилки в ERP API
API-first дає можливість AI-асистенту отримувати:
}
- які бізнес-об’єкти доступні через API;
- які дії можна виконувати;
- які поля передаються;
- які формати даних використовуються;
- які права доступу потрібні;
- які помилки можливі;
- які статуси повертаються;
- як функціонує версіонування;
- як тестується API;
- як API документується;
- як інші системи будуть інтегруватися. {
- локальний агент синхронізації;
- кеш API;
- черга запитів;
- журнал інтеграцій;
- тестове середовище;
- mock API;
- міграційна база. Приклад:
}
API governance — це правила керування API в компанії. Без єдиного словника API оперативно стає незрозумілим.
API — це інтерфейс, через який одна платформа взаємодіє з іншою. Для Power BI API-first означає, що аналітичні інструменти отримує інформаційні дані через стабільний, контрольований шар. API-first потрібен, щоб інтеграції були передбачуваними, документованими, безпечними й стабільними. # Погодили поля.== API-first і тестування == компанія-користувач хоче, щоб мобільний застосунок складу працював з ERP. * 200 — успішне читання;
- 201 — створено;
- 202 — прийнято в обробку;
- 204 — успішно без тіла відповіді;
- 400 — помилка запиту;
- 401 — не авторизовано;
- 403 — заборонено;
- 404 — не знайдено;
- 409 — конфлікт;
- 422 — помилка валідації;
- 500 — помилка сервера. GET /api/v1/products/changes?updated_after=2026-05-15T10:00:00Z
}
external_order_id = WEB-10425
required: true
- які інформаційні дані йдуть з BAS;
- які інформаційні дані йдуть у BAS;
- які зовнішні ID використовуються;
- які обробки запускають обмін;
- які права має користувач системи обміну;
- які журнали помилок виступає як;
- які API потрібні в K2 ERP;
- які старі обміни потрібно вимкнути.== API-first і валюти ==
- сайт здатна створювати замовлення, але не бачить зарплату;
- Power BI здатна читати аналітичні інформаційні дані, але не змінює документи;
- WMS здатна змінювати складські операції, але не фінансовий блок;
- AI-асистент бачить тільки дозволені користувачу інформаційні дані;
- банк-інтеграція функціонує тільки з платежами. Типові API:
- доступ через API;
- правила валідації;
- права доступу;
- аудит;
- стабільний контракт;
- контроль навантаження.
"error_code": "PRODUCT_NOT_FOUND", Підхід оптимізує: == API-first і CRM == Статуси мають бути чітко описані.== API-first і міграція даних == == Приклад retry == == API-first і статуси == * назву API; * SEO-опис; * власника; * версію; * документацію; * статус; * середовища; * endpoint-и; * права доступу; * SLA; * changelog. '''Ідемпотентність''' означає, що повторний однаковий запит не створює небажаних дублювань. Черги корисні для: * описати бізнес-процеси; * визначити системи; * зробити карту інтеграцій; * визначити джерела правди; * описати доменні об’єкти; * створити API-контракти; * погодити OpenAPI; * створити mock API; * написати тести; * реалізувати backend; * підключити frontend і інтеграції; * налаштувати безпеку; * увімкнути моніторинг; * вести changelog. Під час переходу з BAS у K2 ERP потрібно завантажити контрагентів. платформа },
- кількість знаків після коми;
- правила округлення;
- валюту;
- ПДВ;
- знижки;
- суму з податком;
- суму без податку;
- ціну рядка;
- загальну суму;
- формат у JSON. "status": "imported"
Пов’язана сторінка: Інтеграція з BAS
- API отримує запит. Потрібно визначити:
! Приклад успіху:
У пайплайні можна автоматизовано перевіряти:
|- | Endpoint | POST /api/v1/orders |- | Призначення | Створення замовлення клієнта |- | Авторизація | Bearer token |- | Обов’язкові поля | external_order_id, customer, items |- | Успішна відповідь | 201 Created |- | Типові помилки | PRODUCT_NOT_FOUND, DUPLICATE_ORDER, VALIDATION_ERROR |}
! |- | Де застосовується для? GET /customers
Пов’язана сторінка: AI
- які помилки можна повторювати;
- скільки разів повторювати;
- з якою паузою;
- коли відправляти в ручну перевірку;
- як не створити дублікати;
- як функціонує idempotency key. {
Для критичних операцій використовують idempotency key. Кращий підхід:
- читати зарплату;
- змінювати договори;
- проводити платежі;
- отримувати собівартість;
- адмініструвати систему. Backward compatibility означає, що нові зміни не ламають старих клієнтів. * створення платіжного доручення;
- статус платежу;
- завантаження виписки;
- залишок рахунку;
- валютні операції;
- комісії;
- помилки;
- підписання;
- права доступу;
- журнал аудиту. {
POST /orders
- отримати каталог;
- отримати ціни;
- отримати залишки;
- створити замовлення;
- передати оплату;
- отримати статус;
- створити повернення;
- отримати номер ТТН;
- оновити клієнта. Пов’язана сторінка: Казначейство
}
- сайт → ERP;
- CRM → ERP;
- банк → обліковий облік;
- Power BI → звіти;
- мобільний застосунок → складський облік;
- Telegram-бот → заявки. |}
Приклад REST API для ERP
number
delivery_city !== Коротко ==
{
API-first і паралельний запуск ERP
API-first і пагінація
Приклади: Інкрементальна синхронізація дає можливість отримувати тільки зміни після певного моменту. # Погодили правила дублювання. "customer": {
Сценарії:
API здатна повернути:
API-first і sandbox
- немає документації;
- endpoint-и названі хаотично;
- немає версій;
- помилки незрозумілі;
- немає зовнішніх ID;
- немає тестів;
- немає власника;
- API змінюється без попередження;
- інтеграції мають повні права;
- партнери отримують різні формати;
- Power BI читає інформаційні дані напряму з бази. Потрібна пагінація.== API-first і мобільні застосунки ==
"sku": "COFFEE-1KG",
API-контракт — це SEO-опис endpoint-ів, методів, полів, форматів, відповідей, помилок, авторизації, статусів і прикладів використання API. У великому бізнесі API-first стає частиною корпоративної архітектури. Середній час Correlation ID — це ідентифікатор запиту або процесу, який оптимізує відстежити ланцюг подій у різних системах. # Сайт і ERP розробляються паралельно за одним контрактом. конкурентні переваги:
- виробничі замовлення;
- специфікації;
- операції;
- робочі центри;
- матеріали;
- випуск;
- брак;
- простої;
- фактичні витрати;
- статуси виробництва. }
}
Помилки API мають бути видимими.== API-first і rate limiting ==
API-first і CI/CD
"message": "Quantity must be greater than 0" ! API-first потрібен, щоб системи могли стабільно й передбачувано взаємодіяти. ! Метод == Приклад тестів API == * дату; * клієнта; * товарну групу; * суму продажів; * собівартість; * маржу; * менеджера; * підрозділ; * канал продажу. Джерело правди Для нього особливо важливі: == Що таке API-first == Етапи: Команда ERP створила поле: * доступність; * максимальний час відповіді; * час реакції на помилки; * регламент підтримки; * відповідальних; * допустимі вікна обслуговування; * процедуру аварійного відновлення. # Погодили зовнішні ID. Це зменшує хаос, дублікати, помилки й переробки. інформаційні дані API повертає тільки ті заявки, які користувач системи має право бачити. # Виявилося, що в ERP немає зовнішнього ID. # Статуси не збігаються.== API-first і валідація == Тіло запиту: Через API можна підключати: * обхід бізнес-логіки; * обхід прав доступу; * немає аудиту; * залежність від структури таблиць; * складні оновлення версій; * ризик пошкодження даних; * немає стабільного контракту; * Power BI або інтеграційні функції ERP можуть зламатися після зміни схеми. Код ! У контексті [[K2 ERP]] API-first означає, що ERP не виступає як “закритою коробкою”, а має зрозумілі API-контракти для обміну з сайтом, CRM, банком, складом, виробництвом, Power BI, зовнішніми сервісами, міграційними інструментами і AI-рішеннями. Changelog потрібен, щоб команди бачили зміни API. | OpenAPI, версіонування, права доступу, зовнішні ID, ідемпотентність, аудит, моніторинг і тестування. Окремо варто відзначити CRM забезпечується через API-first особливо важливий; так само реалізовано e-commerce, банківських інтеграцій, WMS, MES, Service Desk, мобільних застосунків, BI, Power BI, AI-асистентів, партнерських кабінетів і мікросервісної архітектури. HTTP-статуси мають використовуватися послідовно. ! API здатна дозволяти: '201':
"status": "created"
Пов’язана сторінка: CRM для продажів
API-first і direct database access
post:
Для критичних API потрібен SLA. # ORM читає або записує інформаційні дані. ! Він звертається до API:
Що підготувати перед API-first проєктом
API-first добре поєднується з CI/CD. |- | Який результат? Пов’язана сторінка: ERP для документообігу
POST /payment-requests
"field": "items [0].quantity",
А не:
}
<pre>
== API-first і governance ==
Приклад:
[[Категорія:Паралельний запуск ERP]]
Потрібно визначити:
Поганий підхід:
== API-first і джерело правди ==
"items": [
<pre>
'''Contract-first''' означає, що спочатку описують контракт API, а потім пишуть код. {| class="wikitable" style="width:100%;"
! Приклад:
* не ламати старі інтеграції;
* поступово переводити клієнтів;
* тестувати нові поля;
* підтримувати партнерів;
* контролювати зміни;
* документувати deprecated-методи. # Викликає бізнес-сервіс. Приклад статусів замовлення:
Приклади сервісів:
API-first має включати безпеку з першого етапу. ![[Категорія:Аудит дій]]
Потрібно підготувати:
Які заявки на оплату потрібно погодити сьогодні? | Для стабільних інтеграцій, паралельної розробки, документації, безпеки й меншої кількості переробок. Endpoint
Обмін здатна включати: Partner API — це API для зовнішніх партнерів. як приклад: Якщо клієнт ERP повторить той самий запит із тим самим ключем, API не створить дубль. query {
API-first часто пов’язаний із підходом contract-first. Приклади:
"items": [
- платежі;
- банківські рахунки;
- залишки коштів;
- дебіторка;
- кредиторка;
- зарплата;
- собівартість;
- бюджет;
- маржа;
- договори;
- ліміти. }
- які статуси існують;
- коли замовлення вважається оплаченим;
- чи можна змінювати ціну;
- як функціонує резерв;
- як визначається клієнт ERP;
- які поля обов’язкові;
- як обробляються повернення;
- хто відповідає за помилки. "items": [
Який результат правильного API-first підходу?
Потрібно логувати:
customer(id: 15) {
- сайт;
- API Gateway;
- ERP;
- банк;
- WMS;
- журнал інтеграції;
- Service Desk. order.shipped
| Замовлення за день | 240 | 240 | Збігається |
| Сума оплат | 780 000 грн | 780 000 грн | Збігається |
| Дублі зовнішніх ID | 0 | 0 | Збігається |
| Помилки інтеграції | 12 | 12 | Потрібне виправлення |
API-first і DevOps
- які інформаційні дані ще йдуть у стару систему;
- які інформаційні дані вже йдуть у K2 ERP;
- які API використовуються;
- які інтеграції дублюються;
- як рахуються контрольні суми;
- коли вимикаються старі обміни;
- хто відповідає за розбіжності. Після зміни структури таблиць такі інтеграції швидко ламаються. Хороший API має бути стабільним, документованим, безпечним, версіонованим, тестованим, зрозумілим для бізнесу й технічних команд. * клієнти дублюються;
- замовлення не прив’язуються до правильних контрагентів;
- платежі не закривають борг;
- Power BI показує різні цифри;
- технічна підтримка шукає помилки вручну. | Endpoint-и, поля, формати, відповіді, помилки, авторизацію, версії, статуси й приклади.== API-first і технічний борг ==
Пов’язана сторінка: Power BI
- ERP;
- CRM;
- сайт;
- банк;
- складський облік;
- BI;
- електронний документообіг;
- Service Desk. Коментар
| "sku": "USB-C-1M-BLK",
Без API-first часто буває так: API-first і naming conventions
Для API-first і черги{
Приклади: Банківські інтеграції особливо чутливі до безпеки й контролю.== API-first і ORM == == API-first і доменна модель == Що таке API-first простими словами?2026-05-15T10:30:00Z requestBody: Для сайту API-first означає, що сайт не “лізе в базу ERP напряму”, а функціонує через зрозумілі методи. | В ERP, CRM, сайтах, мобільних застосунках, банках, WMS, MES, Power BI, AI й інтеграціях.== Впровадження API-first == "external_id": "BAS-T-077", Ризики: У K2 ERP API-first здатна бути основою інтеграційної архітектури. API-first для банку має описувати:API-first і логування помилокПриклади:
] Приклад API-контракту
"name": "ТОВ Постачальник",
AI не читає базу напряму. POST /api/v1/products/bulk {
== API-first і моніторинг ==
ERP-системи все більше стають платформами, а не окремими закритими програмами. '''Зовнішній ID''' — це ідентифікатор об’єкта в іншій системі. Напрям
API не має повертати мільйони записів одним запитом. В API-first спочатку погоджують контракт API, поля, помилки, версії та правила обміну.== Приклад code-first проблеми ==
API-first і SQLiteRate limiting обмежує кількість запитів за певний час. POST /api/v1/orders OpenAPI дає можливість описати: Потрібні: contact_external_id SQLite здатна використовуватися в API-first архітектурі як локальне або проміжне сховище. } Простий приклад API-first
API-first і deprecated APIяк приклад: API-first і заміна BASAPI-first дає можливість ERP бути: ]API-first оптимізує зробити інтеграції керованими, а не залежними від випадкових файлів і ручних обробок.
* описати старі інтеграції BAS;
* знайти зовнішні обробки;
* знайти API або файли обміну;
* описати зовнішні ID;
* створити нові API в K2 ERP;
* протестувати обмін;
* перенести Power BI;
* вимкнути старі інтеграції після запуску. {| class="wikitable" style="width:100%;"
* створити договір;
* передати файл;
* отримати статус підписання;
* отримати підписаний PDF;
* перевірити контрагента;
* передати акт;
* зв’язати документ із замовленням;
* нагадати про строк дії. Мінус здатна означати сортування за спаданням. # API повертає відповідь. "error_code": "RATE_LIMIT_EXCEEDED",
Це потрібно, щоб:
AI-рішенням потрібен контрольований доступ до даних. "sku": "USB-C-1M-BLK",
У code-first спочатку пишуть код, а API описують пізніше. {| class="wikitable" style="width:100%;"
== API-first і changed_at ==
! # У сайту інший формат товарів. Краще:
* перейменувати поле;
* змінити тип даних;
* видалити поле;
* змінити формат дати;
* змінити логіку статусів;
* змінити авторизацію без перехідного періоду. інформаційні дані
{
Приклад:
<pre>
критично, щоб API не був без зусиль “обгорткою над таблицями”.=== Чим API-first відрізняється від code-first? ===
"payment_status": "paid",
API має логувати важливі дії. Відповідь має показати, які записи успішні, а які з помилками. } як приклад: GET /api/v1/products?sort=name критично. API-first не означає “зробити багато endpoint-ів”. |-
|
|---|