HTTP-сервіси 1С

HTTP-сервіси 1С — це механізм платформи 1С / 1С:Підприємство, який дозволяє створювати HTTP endpoint-и для зовнішніх систем. Через HTTP-сервіси 1С може приймати і віддавати дані через HTTP-запити, наприклад у форматі JSON або XML. Такі сервіси використовуються для інтеграцій із сайтами, CRM, WMS, MES, банками, мобільними застосунками, зовнішніми API, сервісами доставки, маркетплейсами, BI-системами та міграційними інструментами.

HTTP-сервіс у 1С можна розглядати як власний API всередині конфігурації. Зовнішня система надсилає GET, POST, PUT або DELETE-запит, а 1С обробляє його кодом мовою 1С і повертає відповідь.

Головне. HTTP-сервіс 1С — це спосіб зробити API до 1С/BAS: прийняти замовлення з сайту, віддати залишки, оновити статус, отримати оплату, передати ціни або підготувати дані для міграції.

Проста аналогія. HTTP-сервіс — це “двері” в 1С для інших програм. Але ці двері мають мати замок, журнал відвідувачів, правила доступу і контроль того, хто що може робити.

Важливо про 1С та BAS. В Україні продукти екосистеми 1С і частина продуктів BAS пов’язані з санкційними, юридичними, кібербезпековими та репутаційними ризиками. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. Перед підтримкою, використанням або міграцією таких систем потрібно перевіряти актуальні офіційні обмеження. ([cip.gov.ua](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [president.gov.ua](https://www.president.gov.ua/documents/6012024-52009))

Що таке HTTP-сервіс 1С

HTTP-сервіс 1С — це об’єкт конфігурації, який дозволяє описати URL-шлях, HTTP-методи і код обробки запитів.

Через HTTP-сервіс зовнішня система може:

отримати список товарів;
отримати залишки;
отримати ціни;
передати замовлення;
передати оплату;
оновити статус документа;
отримати інформацію про контрагента;
завантажити довідник;
створити документ;
виконати перевірку наявності товару;
передати дані для інтеграції;
отримати контрольні суми;
запустити міграційне вивантаження.

HTTP-сервіси часто використовуються як альтернатива COM-з’єднанню, файловому обміну, FTP, ручним обробкам або старим SOAP/XML-інтеграціям.

Для чого потрібні HTTP-сервіси

HTTP-сервіси потрібні для інтеграції 1С/BAS із зовнішнім світом.

Типові сценарії:

сайт передає замовлення в 1С;
CRM отримує статуси оплат;
WMS отримує завдання на відвантаження;
MES отримує виробничі замовлення;
банк передає статус платежу;
мобільний застосунок отримує залишки;
маркетплейс отримує ціни;
Power BI або аналітичний шар отримує дані;
K2 ERP отримує дані під час міграції;
зовнішня система перевіряє контрагента;
служба доставки отримує дані для ТТН.

Практичний сенс. HTTP-сервіси дозволяють не обмінюватися файлами вручну, а зробити керований API, через який системи автоматично передають дані.

HTTP-сервіс і REST API

HTTP-сервіс 1С часто використовують для побудови REST-подібного API.

Наприклад:

Метод	URL	Дія
GET	/hs/api/products	Отримати товари
GET	/hs/api/stock?warehouse=MAIN	Отримати залишки
POST	/hs/api/orders	Створити замовлення
POST	/hs/api/payments	Завантажити оплату
PUT	/hs/api/orders/WEB-10025/status	Оновити статус
DELETE	/hs/api/orders/WEB-10025	Скасувати або видалити, якщо така логіка дозволена

У 1С це не завжди “чистий REST” у строгому архітектурному сенсі, але для бізнес-інтеграцій такий підхід часто достатній.

HTTP-сервіс і web-сервіс 1С

Не варто плутати HTTP-сервіси і web-сервіси 1С.

Механізм	Формат	Типове використання
HTTP-сервіс	REST-подібний HTTP, JSON, XML, текст	Сучасні інтеграції, API, мобільні застосунки
Web-сервіс	SOAP/XML	Старі корпоративні інтеграції, формальні SOAP-схеми
COM-з’єднання	COM Automation	Старі Windows-інтеграції, Excel, C#, PowerShell
Файловий обмін	XML, CSV, TXT, DBF	Старі або прості обміни через папки

Для нових інтеграцій частіше краще HTTP-сервіс із JSON.

Як працює HTTP-сервіс

Типова схема:

Зовнішня система
    ↓ HTTP-запит
Web-сервер
    ↓
Сервер 1С
    ↓
Код HTTP-сервісу
    ↓
Довідники, документи, регістри, запити
    ↓
HTTP-відповідь

Наприклад:

Сайт надсилає POST-запит із JSON-замовленням.
Web-сервер передає запит у 1С.
1С викликає метод HTTP-сервісу.
Код перевіряє авторизацію.
Код читає JSON.
Код створює замовлення покупця.
Код записує зовнішній ID.
Код повертає JSON-відповідь зі статусом.

Публікація HTTP-сервісу

Щоб HTTP-сервіс був доступний зовні, інформаційну базу потрібно опублікувати на web-сервері.

Зазвичай використовується схема:

web-сервер;
опублікована інформаційна база;
HTTP-сервіс у конфігурації;
користувач або механізм авторизації;
правила мережевого доступу;
HTTPS;
firewall;
reverse proxy, якщо використовується.

Публікація API без контролю доступу є серйозним ризиком безпеки.

Структура HTTP-сервісу в конфігурації

HTTP-сервіс зазвичай містить:

ім’я сервісу;
кореневий URL;
шаблони URL;
HTTP-методи;
обробники методів;
параметри шляху;
параметри запиту;
код відповіді;
заголовки;
тіло відповіді.

Наприклад:

HTTPСервис: API
Шаблон URL: /orders
Метод: POST
Обработчик: СтворитиЗамовлення

HTTP-методи

Основні HTTP-методи:

Метод	Призначення	Приклад у 1С
GET	Отримати дані	Отримати залишки товарів
POST	Створити або передати дані	Створити замовлення
PUT	Оновити дані	Оновити статус замовлення
PATCH	Частково оновити дані	Оновити тільки поле статусу
DELETE	Видалити або скасувати	Скасувати замовлення

У бізнес-системах DELETE часто краще реалізовувати не як фізичне видалення, а як скасування або зміну статусу.

GET-запит у HTTP-сервісі

GET використовується для отримання даних.

Приклад URL:

GET /hs/api/stock?warehouse=MAIN&date=2026-05-15

Типова відповідь:

{
  "warehouse": "MAIN",
  "date": "2026-05-15",
  "items": [
    {
      "sku": "SKU-001",
      "quantity": 25
    },
    {
      "sku": "SKU-002",
      "quantity": 10
    }
  ]
}

GET-запит не повинен змінювати дані. Його краще використовувати тільки для читання.

POST-запит у HTTP-сервісі

POST використовується для створення або передачі даних.

Приклад:

POST /hs/api/orders
Content-Type: application/json

Тіло запиту:

{
  "external_id": "WEB-10025",
  "date": "2026-05-15T10:30:00",
  "customer": {
    "code": "12345678",
    "name": "ТОВ Ромашка"
  },
  "items": [
    {
      "sku": "SKU-001",
      "quantity": 2,
      "price": 1200
    }
  ]
}

Типова відповідь:

{
  "status": "success",
  "external_id": "WEB-10025",
  "document_ref": "000000123",
  "message": "Order created"
}

Приклад обробника GET у 1С

Спрощений приклад:

Функция ОтриматиЗалишки(Запрос)

    СкладКод = Запрос.ПараметрыURL.Получить("warehouse");

    Данные = Новый Структура;
    Данные.Вставить("warehouse", СкладКод);
    Данные.Вставить("date", Формат(ТекущаяДата(), "ДФ=yyyy-MM-dd"));

    Товари = Новый Массив;

    // Тут має бути запит до регістру залишків

    Данные.Вставить("items", Товари);

    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Данные);
    ТелоОтвета = ЗаписьJSON.Закрыть();

    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(ТелоОтвета, КодировкаТекста.UTF8);

    Возврат Ответ;

КонецФункции

Це спрощений приклад для ілюстрації логіки.

Приклад обробника POST у 1С

Спрощена логіка створення замовлення:

Функция СтворитиЗамовлення(Запрос)

    Тело = Запрос.ПолучитьТелоКакСтроку();

    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Тело);

    Данные = ПрочитатьJSON(ЧтениеJSON);

    ExternalID = Данные.external_id;

    Если ЗамовленняВжеІснує(ExternalID) Тогда
        Возврат ВідповідьJSON(200, "exists", "Order already exists");
    КонецЕсли;

    // Тут створюється документ замовлення покупця
    // Заповнюється контрагент, товари, ціни, склад, ПДВ

    Возврат ВідповідьJSON(201, "success", "Order created");

КонецФункции

У реальному коді потрібно обробляти помилки, права, транзакції, обов’язкові поля, external_id і логування.

Функція відповіді JSON

Приклад допоміжної функції:

Функция ВідповідьJSON(КодСтану, Статус, Повідомлення)

    Данные = Новый Структура;
    Данные.Вставить("status", Статус);
    Данные.Вставить("message", Повідомлення);

    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Данные);
    Тело = ЗаписьJSON.Закрыть();

    Ответ = Новый HTTPСервисОтвет(КодСтану);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(Тело, КодировкаТекста.UTF8);

    Возврат Ответ;

КонецФункции

Таку функцію зручно винести в загальний модуль.

HTTP-коди відповідей

HTTP-сервіс має повертати правильні коди.

Код	Значення	Приклад
200	Успішно	Дані отримано
201	Створено	Замовлення створене
400	Неправильний запит	Немає обов’язкового поля
401	Не авторизовано	Немає або неправильний токен
403	Заборонено	Користувач не має прав
404	Не знайдено	Товар або замовлення не знайдені
409	Конфлікт	Документ уже існує
500	Внутрішня помилка	Помилка коду або бази

Погана практика — завжди повертати 200 навіть при помилці.

JSON у HTTP-сервісах

JSON — найпоширеніший формат для сучасних HTTP API.

Переваги:

компактний;
зручний для web API;
добре підтримується більшістю мов;
легко читати;
підходить для REST;
зручний для мобільних застосунків.

Приклад відповіді:

{
  "status": "success",
  "data": {
    "sku": "SKU-001",
    "quantity": 25
  }
}

XML у HTTP-сервісах

HTTP-сервіс може працювати і з XML.

Приклад:

<Order>
    <ExternalID>WEB-10025</ExternalID>
    <Date>2026-05-15</Date>
    <CustomerCode>12345678</CustomerCode>
</Order>

XML може бути потрібен для:

старих систем;
CommerceML;
SOAP-подібних обмінів;
електронного документообігу;
державних або корпоративних форматів.

Але для нових інтеграцій зазвичай зручніше JSON.

Авторизація HTTP-сервісів

HTTP-сервіс не можна залишати відкритим без авторизації.

Можливі варіанти:

базова авторизація web-сервера;
користувач 1С;
API-ключ;
Bearer token;
HMAC-підпис;
IP whitelist;
reverse proxy з авторизацією;
VPN;
сертифікати;
поєднання кількох механізмів.

Для критичних даних одного IP whitelist недостатньо. Потрібна повноцінна авторизація і журналювання.

API-ключ

Простий варіант — API-ключ у заголовку.

Приклад:

Authorization: Bearer eyJhbGciOi...

або:

X-API-Key: 1234567890abcdef

У 1С код має перевірити ключ до виконання бізнес-логіки.

Приклад перевірки токена

Спрощена логіка:

Функция ПеревіритиАвторизацію(Запрос)

    Токен = Запрос.Заголовки.Получить("Authorization");

    Если Не ЗначениеЗаполнено(Токен) Тогда
        Возврат Ложь;
    КонецЕсли;

    Если Токен <> "Bearer secret-token" Тогда
        Возврат Ложь;
    КонецЕсли;

    Возврат Истина;

КонецФункции

У реальному проєкті токен не можна зберігати відкритим текстом у коді. Його краще зберігати в захищених налаштуваннях або окремому сховищі секретів.

HTTPS

HTTP-сервіси з бізнес-даними мають працювати через HTTPS.

Без HTTPS можна перехопити:

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

Критично. HTTP-сервіс із записом документів, оплат, цін або персональних даних не можна публікувати у відкритий інтернет без HTTPS, авторизації, журналу, обмеження прав і моніторингу.

Права користувача HTTP-сервісу

HTTP-сервіс часто виконується від імені користувача 1С або службового користувача.

Цей користувач має мати мінімальні права:

читати потрібні довідники;
створювати потрібні документи;
не бачити зайві дані;
не мати повних прав;
не мати доступу до зарплати без потреби;
не мати доступу до банку без потреби;
не мати доступу до конфігуратора;
не мати доступу до небезпечних обробок.

Погана практика — запускати API від імені адміністратора.

Валідація запитів

Перед записом даних потрібно перевіряти:

наявність обов’язкових полів;
типи даних;
формат дат;
валюту;
суму;
ПДВ;
номенклатуру;
контрагента;
склад;
зовнішній ID;
дублікати;
допустимий статус;
права;
розмір тіла запиту.

Приклад помилки:

{
  "status": "error",
  "code": "missing_required_field",
  "message": "Field external_id is required"
}

External ID

Для HTTP-інтеграцій критично важливий зовнішній ID.

Приклад:

{
  "external_id": "WEB-10025"
}

External ID потрібен, щоб:

не створити дубль;
знайти документ при повторному запиті;
оновити статус;
зв’язати 1С і зовнішню систему;
обробити повтор після помилки;
зробити ідемпотентний API.

Ідемпотентність

Ідемпотентність означає, що повторний однаковий запит не створює дублікати.

Погано:

POST /orders з тим самим external_id щоразу створює новий документ.

Добре:

POST /orders з тим самим external_id повертає існуючий документ або оновлює його за правилами.

Для цього потрібно зберігати external_id у документі або окремому регістрі відомостей.

Логування HTTP-сервісів

Потрібно логувати кожен важливий запит.

Лог має містити:

дату і час;
endpoint;
метод;
IP;
користувача або токен;
external_id;
статус;
HTTP-код;
час виконання;
текст помилки;
ID створеного документа;
кількість рядків;
розмір запиту;
ідентифікатор кореляції.

Приклад журналу:

Час	Метод	URL	External ID	Статус	Код
15.05.2026 10:30	POST	/orders	WEB-10025	success	201
15.05.2026 10:31	POST	/orders	WEB-10026	error	400

Correlation ID

Correlation ID — це ідентифікатор запиту, який допомагає знайти один і той самий запит у різних системах.

Приклад заголовка:

X-Correlation-ID: 7b9f4c2e-1d22-4a9d-9201-abc123

Його корисно записувати в журнал 1С, журнал web-сервера і журнал зовнішньої системи.

Обробка помилок

HTTP-сервіс має повертати зрозумілі помилки.

Погана відповідь:

{
  "error": "Ошибка"
}

Краща відповідь:

{
  "status": "error",
  "code": "product_not_found",
  "message": "Product with SKU SKU-001 not found",
  "correlation_id": "7b9f4c2e-1d22-4a9d-9201-abc123"
}

Так зовнішній системі легше зрозуміти, що саме сталося.

Типові HTTP endpoint-и для 1С

Endpoint	Метод	Призначення
/products	GET	Список товарів
/products/{sku}	GET	Дані товару
/stock	GET	Залишки
/prices	GET	Ціни
/orders	POST	Створення замовлення
/orders/{id}	GET	Отримання замовлення
/orders/{id}/status	PUT	Оновлення статусу
/payments	POST	Завантаження оплат
/counterparties	POST	Створення або оновлення контрагентів

HTTP-сервіс для сайту

Типовий сценарій інтеграції з сайтом:

сайт передає замовлення в 1С;
1С повертає номер документа;
1С передає залишки на сайт;
1С передає ціни;
сайт отримує статус оплати;
1С отримує статус доставки;
обидві системи використовують external_id.

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

{
  "status": "success",
  "external_id": "WEB-10025",
  "order_number": "000000123",
  "created": true
}

HTTP-сервіс для залишків

Залишки краще отримувати з регістрів, а не з документів.

Типова логіка:

Отримати склад і дату з параметрів.
Перевірити права.
Виконати запит до регістру накопичення.
Сформувати JSON.
Повернути відповідь.

Потрібно враховувати:

склад;
дату;
характеристику;
серію;
партію;
резерв;
доступний залишок;
одиницю виміру.

HTTP-сервіс для цін

Ціни можуть залежати від:

типу ціни;
валюти;
дати;
номенклатури;
характеристики;
контрагента;
знижок;
прайс-листа.

Приклад:

{
  "price_type": "RETAIL",
  "currency": "UAH",
  "date": "2026-05-15",
  "items": [
    {
      "sku": "SKU-001",
      "price": 1200
    }
  ]
}

HTTP-сервіс для оплат

Оплата може приходити з банку, платіжного сервісу або сайту.

Приклад:

{
  "transaction_id": "PAY-98765",
  "date": "2026-05-15T12:00:00",
  "amount": 2400,
  "currency": "UAH",
  "purpose": "Payment for order WEB-10025",
  "order_external_id": "WEB-10025"
}

Для оплат обов’язково потрібен transaction_id, щоб не завантажити одну оплату двічі.

HTTP-сервіс і банк

Інтеграція з банками через HTTP-сервіси може включати:

прийом webhook про платіж;
отримання виписки;
передачу платіжного доручення;
перевірку статусу;
обробку комісії;
звірку транзакцій.

Банківські endpoint-и потребують посиленого захисту: HTTPS, токени, IP-обмеження, журналювання і контроль дублів.

HTTP-сервіс і WMS

WMS може отримувати з 1С:

замовлення на відвантаження;
переміщення;
залишки;
довідник товарів;
штрихкоди;
партії;
серії;
характеристики.

WMS може передавати в 1С:

факт відбору;
факт пакування;
факт відвантаження;
інвентаризацію;
серії;
партії;
розбіжності.

HTTP-сервіс і виробництво

MES або виробнича система може інтегруватися з 1С через HTTP.

Можливі сценарії:

отримати виробниче замовлення;
отримати специфікацію;
передати факт випуску;
передати списання матеріалів;
передати брак;
передати НЗВ;
отримати залишки матеріалів.

Для виробництва важливо контролювати партії, специфікації, напівфабрикати і собівартість.

HTTP-сервіс і Power BI

HTTP-сервіс може віддавати дані для аналітики, але робити це потрібно обережно.

Проблеми:

великі обсяги;
довгі запити;
навантаження на робочу базу;
відсутність пагінації;
немає кешу;
багато користувачів BI одночасно;
дані без обмеження періоду.

Для регулярної аналітики краще використовувати окремий BI-шар, репліку, сховище або Power BI-датасет, а не постійно навантажувати робочу базу HTTP-запитами.

Пагінація

Якщо endpoint повертає багато даних, потрібна пагінація.

Приклад:

GET /hs/api/products?page=1&page_size=100

Відповідь:

{
  "page": 1,
  "page_size": 100,
  "total": 2500,
  "items": []
}

Без пагінації великий запит може перевантажити 1С.

Обмеження розміру запиту

HTTP-сервіс має обмежувати розмір тіла запиту.

Наприклад:

не приймати файл на сотні мегабайт;
розбивати великі імпорти на частини;
використовувати чергу;
приймати тільки зміни;
повертати помилку при перевищенні ліміту.

Приклад відповіді:

{
  "status": "error",
  "code": "payload_too_large",
  "message": "Request body is too large"
}

Черга обробки

Для важких запитів краще не виконувати всю логіку одразу.

Кращий підхід:

HTTP-сервіс приймає запит.
Перевіряє формат.
Записує завдання в чергу.
Повертає ID завдання.
Фонове або регламентне завдання обробляє дані.
Зовнішня система перевіряє статус.

Приклад відповіді:

{
  "status": "accepted",
  "job_id": "JOB-20260515-0001"
}

Це зменшує ризик таймаутів і блокувань.

Таймаути

HTTP-запити мають обмеження часу.

Проблеми виникають, якщо:

створюється багато документів;
проводяться документи;
виконується важкий запит;
зовнішня система чекає надто довго;
web-сервер обриває з’єднання;
1С заблокована іншою операцією.

Для довгих процесів краще використовувати асинхронну обробку через job_id.

Типові помилки HTTP-сервісів 1С

Помилка	Причина	Наслідок
Сервіс відкритий без авторизації	API опублікували без захисту	Витік або зміна даних
Завжди повертається 200	Помилки не відображаються HTTP-кодами	Зовнішня система не розуміє проблему
Немає external_id	Не контролюються дублікати	Документи створюються повторно
Важка логіка в одному POST	Документи створюються і проводяться синхронно	Таймаути і блокування
Немає логування	Помилки не зберігаються	Неможливо підтримувати інтеграцію
API працює від адміністратора	Службовому користувачу дали повні права	Ризик витоку і зміни даних
Немає HTTPS	Дані передаються відкрито	Перехоплення токенів і даних

Помилка: HTTP 404

Можливі причини:

база не опублікована;
неправильний URL;
неправильна назва сервісу;
неправильний шлях шаблону;
web-сервер не налаштований;
сервіс не включений у конфігурації;
зміни не оновлені в базі;
URL має інший регістр або структуру.

Що перевірити:

Публікацію бази.
Назву HTTP-сервісу.
Шаблон URL.
Web-сервер.
Адресу /hs/.
Версію конфігурації.
Журнал помилок.

Помилка: HTTP 401 або 403

Можливі причини:

немає токена;
неправильний токен;
неправильний користувач;
недостатньо прав;
IP не дозволений;
web-сервер блокує запит;
сервіс вимагає іншу авторизацію.

Важливо відрізняти:

401 — користувач не авторизований;
403 — користувач авторизований, але дія заборонена.

Помилка: HTTP 500

HTTP 500 означає внутрішню помилку.

Можливі причини:

помилка коду 1С;
не знайдено реквізит;
неправильний JSON;
помилка запису документа;
немає прав;
помилка транзакції;
помилка проведення;
блокування;
недоступна СУБД;
помилка розширення.

У відповіді не варто показувати зовнішньому користувачу повний внутрішній текст помилки з технічними деталями. Деталі краще зберігати в журналі.

Помилка: дублюються замовлення

Причини:

немає external_id;
external_id не унікальний;
документ створюється до перевірки;
повторний POST після таймауту створює новий документ;
немає журналу запитів;
немає ідемпотентності.

Рішення:

зробити external_id обов’язковим;
зберігати його в документі або регістрі;
перевіряти перед створенням;
повертати 409 або 200 з інформацією про існуючий документ;
логувати повтори.

Помилка: API повільне

Причини:

важкі запити;
запити в циклі;
багато документів у одному запиті;
проведення в синхронному режимі;
немає пагінації;
немає індексів для external_id;
endpoint читає документи замість регістрів;
працює в робочий час;
паралельно йде закриття місяця;
слабкий сервер 1С або СУБД.

Рішення:

оптимізувати запити;
додати пагінацію;
використовувати регістри;
виносити важкі операції в фон;
додати чергу;
обмежити розмір запиту;
кешувати довідкові дані;
запускати великі обміни за розкладом.

HTTP-сервіси і розширення

Розширення 1С можуть додавати або змінювати HTTP-сервіси.

Переваги:

можна не змінювати основну конфігурацію;
зручно додати API для інтеграції;
легше підтримувати окрему логіку;
можна швидше тестувати зміни.

Ризики:

після оновлення розширення може зламатися;
endpoint може конфліктувати;
права можуть бути не враховані;
логіка може дублювати типову;
немає документації;
сервіс може залишитися активним після завершення проєкту.

HTTP-сервіси і адміністрування

Адміністратор має знати:

які HTTP-сервіси опубліковані;
які URL доступні;
хто ними користується;
які методи дозволені;
яка авторизація;
які користувачі 1С використовуються;
які права вони мають;
де зберігаються токени;
де журнали;
які IP дозволені;
хто відповідальний за інтеграцію;
як відключити сервіс у разі інциденту.

Документація API

Для HTTP-сервісу потрібна документація.

У ній має бути:

базовий URL;
список endpoint-ів;
методи;
заголовки;
авторизація;
приклади запитів;
приклади відповідей;
HTTP-коди;
поля;
типи даних;
обов’язкові поля;
помилки;
правила external_id;
обмеження;
контакти відповідальних.

Без документації API швидко стає незрозумілим навіть для тих, хто його створював.

Приклад документації endpoint-а

Поле	Значення
Метод	POST
URL	/hs/api/orders
Формат	JSON
Авторизація	Bearer token
Обов’язкові поля	external_id, date, customer, items
Успішна відповідь	201 Created
Дубль	409 Conflict або 200 з existing=true
Помилки	400, 401, 403, 500

Безпека HTTP-сервісів

HTTP-сервіси мають підвищений ризик, бо можуть бути доступні з мережі.

Потрібно контролювати:

HTTPS;
авторизацію;
токени;
права користувача;
firewall;
IP whitelist;
reverse proxy;
WAF, якщо використовується;
обмеження методів;
обмеження розміру запиту;
журналювання;
захист персональних даних;
захист банківських даних;
захист зарплати;
захист цін і собівартості;
оновлення платформи;
відключення непотрібних endpoint-ів.

Що не можна робити в HTTP-сервісі

Погані практики:

відкривати API без авторизації;
використовувати адміністратора 1С;
зберігати токен у коді відкритим текстом;
повертати повний текст внутрішньої помилки;
приймати будь-який JSON без перевірки;
створювати документи без external_id;
проводити все синхронно без черги;
не логувати запити;
не обмежувати розмір запиту;
дозволяти DELETE для фізичного видалення важливих об’єктів;
відкривати endpoint-и в інтернет без HTTPS.

HTTP-сервіси і міграція з 1С/BAS

Під час переходу з 1С або BAS у K2 ERP HTTP-сервіси можуть бути:

джерелом даних для міграції;
тимчасовим bridge між старою і новою системою;
старою інтеграцією, яку потрібно замінити;
способом паралельного запуску;
джерелом контрольних сум;
каналом для синхронізації довідників.

Через HTTP-сервіси можна тимчасово отримувати з 1С:

довідники;
документи;
залишки;
ціни;
взаєморозрахунки;
статуси;
зовнішні ID;
контрольні звіти.

Що перевірити перед міграцією HTTP-сервісів

Перед міграцією потрібно зібрати:

список HTTP-сервісів;
список endpoint-ів;
методи;
приклади запитів;
приклади відповідей;
авторизацію;
токени;
користувачів 1С;
права;
журнали;
external_id;
залежні зовнішні системи;
розклад викликів;
обсяги даних;
помилки;
відповідальних;
бізнес-процеси, які залежать від API.

Варіанти перенесення HTTP-сервісів у K2 ERP

HTTP-сервіс у 1С/BAS	Варіант у K2 ERP	Коментар
API замовлень	REST API K2 ERP	Потрібні external_id і статуси
API залишків	Stock API або BI-шар	Важлива продуктивність
API цін	Price API	Потрібні типи цін і валюти
API оплат	Payment API / bank integration	Потрібний transaction_id
API довідників	Master data API	Потрібна дедублікація
API для Power BI	Data warehouse / Power BI dataset	Краще не навантажувати ERP напряму
Тимчасовий bridge	Integration layer	Використовується під час паралельного запуску

Карта міграції HTTP API

Елемент 1С HTTP-сервісу	Що означає	Аналог у K2 ERP	Контроль
Endpoint	URL методу	API route	Метод, версія, доступ
Метод GET/POST	Тип операції	API method	Читання чи запис
JSON/XML	Формат обміну	JSON/API schema	Валідація
Token	Авторизація	API token/OAuth	Захист секретів
External ID	Зовнішній ключ	External reference	Захист від дублів
Журнал	Історія викликів	Integration log	Помилки і повтори
Регламентне завдання	Фонова обробка	Background job	Розклад і статус

Контрольні суми після міграції HTTP-сервісів

Після перенесення потрібно звірити:

кількість замовлень;
кількість оплат;
суми документів;
залишки;
ціни;
контрагентів;
номенклатуру;
зовнішні ID;
статуси;
кількість помилок;
дублікати;
час відповіді API;
відповідність JSON-схеми;
результати контрольних звітів.

Реплікатор K2 і HTTP-сервіси 1С

Реплікатор K2 може допомогти при переході з HTTP-інтеграцій 1С або BAS у K2 ERP.

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

аналізу старих endpoint-ів;
вивантаження довідників;
вивантаження документів;
вивантаження регістрів;
формування контрольних сум;
перевірки external_id;
підготовки JSON;
заміни старих HTTP API;
підготовки даних для Power BI;
паралельного запуску 1С/BAS і K2 ERP;
порівняння старої і нової системи.

HTTP-сервіси в сучасній ERP-архітектурі

У сучасній ERP-архітектурі HTTP API має бути:

версійним;
документованим;
захищеним;
ідемпотентним;
логованим;
контрольованим за правами;
із валідацією;
із правильними HTTP-кодами;
із моніторингом;
із захистом секретів;
із підтримкою повторів;
із можливістю масштабування.

У K2 ERP HTTP-інтеграції краще будувати не як хаотичні endpoint-и, а як контрольований API-шар із правами, логами, токенами, схемами, версіями і моніторингом.

Санкції та ризики використання 1С/BAS в Україні

При описі HTTP-сервісів 1С і BAS в українському контексті потрібно згадувати санкційні та безпекові ризики.

1С історично є російською програмною екосистемою. Після початку російської агресії проти України використання такого програмного забезпечення стало питанням не тільки бухгалтерії, а й кібербезпеки, комплаєнсу, репутації та цифрової незалежності.

Держспецзв’язку веде перелік забороненого до використання програмного забезпечення та комунікаційного обладнання; у переліку згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до персональних спеціальних економічних та інших санкцій. ([cip.gov.ua](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [president.gov.ua](https://www.president.gov.ua/documents/6012024-52009))

Важливо. HTTP-сервіси 1С/BAS можуть відкривати зовнішнім системам доступ до критичних бізнес-даних: замовлень, оплат, банку, складу, зарплати, ПДВ, виробництва, контрагентів, персональних даних, цін і собівартості. Якщо такі сервіси працюють у ризиковому або підсанкційному ПЗ, компанії потрібно оцінити юридичні, технічні й кібербезпекові ризики та планувати перехід на безпечну ERP-платформу.

Типові питання

Що таке HTTP-сервіс 1С?

HTTP-сервіс 1С — це механізм платформи, який дозволяє створити HTTP endpoint для зовнішніх систем і обробляти GET, POST, PUT, DELETE-запити кодом 1С.

Для чого використовують HTTP-сервіси 1С?

Для інтеграцій із сайтами, CRM, WMS, MES, банками, мобільними застосунками, Power BI, маркетплейсами, зовнішніми API і міграційними інструментами.

Що краще для HTTP-сервісу: JSON чи XML?

Для сучасних API частіше краще JSON. XML доречний для старих систем, CommerceML, SOAP-подібних обмінів або форматів, де XML уже є стандартом.

Чи можна публікувати HTTP-сервіс 1С в інтернет?

Можна тільки з належним захистом: HTTPS, авторизація, токени, обмеження прав, firewall, журналювання, перевірка запитів, обмеження розміру і моніторинг.

Чому дублюються замовлення через HTTP-сервіс?

Найчастіше через відсутність external_id, журналу обміну й ідемпотентної логіки. Повторний POST після таймауту створює новий документ.

Що важливо при міграції HTTP-сервісів у K2 ERP?

Потрібно знайти всі endpoint-и, описати запити й відповіді, external_id, авторизацію, права, журнали, залежні системи і перенести логіку в сучасний API K2 ERP або інтеграційний шар.

Коротко

Питання	Відповідь
Що таке HTTP-сервіс 1С?	API endpoint у 1С/BAS для обробки HTTP-запитів.
Для чого потрібен?	Для інтеграцій із сайтами, CRM, WMS, MES, банками, BI і зовнішніми системами.
Які формати використовуються?	Найчастіше JSON, іноді XML.
Що найважливіше?	HTTPS, авторизація, external_id, логування, валідація, права і контроль дублів.
Що найчастіше ламається?	Авторизація, URL, JSON, дублікати, таймаути, повільні запити, права.
Що краще для нових інтеграцій?	Документований REST API з JSON, логами, токенами, статусами і моніторингом.

Висновок

HTTP-сервіси 1С — це потужний механізм для створення API всередині 1С/BAS. Через них можна приймати замовлення, передавати залишки, оновлювати ціни, отримувати платежі, синхронізувати довідники, обмінюватися статусами і будувати інтеграції з іншими системами.

Сильна сторона HTTP-сервісів — універсальність і зручність для сучасних інтеграцій. Слабка сторона — високі вимоги до безпеки, логування, авторизації, продуктивності, обробки помилок і контролю дублів.

HTTP-сервіс 1С — це не просто URL. Це повноцінна точка входу в ERP, яка може читати і змінювати критичні бізнес-дані.

При переході з 1С або BAS у K2 ERP HTTP-сервіси потрібно інвентаризувати окремо. Саме через них можуть працювати сайти, банки, CRM, WMS, MES, мобільні застосунки, Power BI та інші важливі бізнес-процеси.

Правильна міграція — це не копіювання старих endpoint-ів “як є”, а перенесення корисної інтеграційної логіки в сучасну ERP-архітектуру: REST API, JSON, версії API, токени, audit log, фонові задачі, черги, Power BI, контроль прав і моніторинг.

Див. також

Зовнішні посилання