Для розробників

Простий REST API без магії

JSON, SHA-256, Webhook, чітке версіювання та RequestID на всьому маршруті запиту.

Інтеграція

Все, що потрібно для швидкого підключення

REST + JSON

Звичайні HTTP-запити та структуровані відповіді без власних бінарних форматів.

SHA-256

Хеш1 перевіряє 7A. Хеш2 перевіряє постачальник власним Ключ2. У QR передаються 32 hex-символи кожного хешу.

Webhook

Покупець ніколи не бачить адресу Webhook постачальника.

RequestID

Один ідентифікатор супроводжує QR-запит, Webhook і відповідь.

Protocol v1

QR використовує GET /Doc та параметри P1–P5. Номер накладної нормалізується у верхній регістр, хеші — 32 lowercase hex-символи.

OpenAPI

Swagger-схема для endpoint-ів, параметрів, статусів та прикладів.

Хеш1 / Хеш2

Єдине правило формування хешів

Для обох хешів використовується SHA-256 від одного UTF-8 рядка. Перед розрахунком номер накладної переводиться у верхній регістр. Для Хеш1 у кінці рядка використовується Ключ1, для Хеш2 — Ключ2.

hash-rule.txt
НомерНакладної_YYYYMMDD_Ключ

ІВ0001542_20260827_32AF58B2C7

SHA-256:
f2c2985c5d351aead707fab68561f0a89ad59918ccc978772726c34be15e639f

У QR:
f2c2985c5d351aead707fab68561f0a8

Правила сумісності

  • Кодування рядка — UTF-8.
  • Номер накладної перед розрахунком завжди переводиться у верхній регістр.
  • Дата — тільки у форматі YYYYMMDD.
  • Розділювач між частинами — символ «_».
  • Зайві пробіли не додаються.
  • У QR значення Хеш1 та Хеш2 передаються у lowercase hex.
  • Повний SHA-256 має 64 hex-символи, але в QR передаються лише перші 32 символи.

Формат QR URL

Публічний QR використовує endpoint GET /Doc на api.7a.com.ua.

QR URL
https://api.7a.com.ua/Doc?P1=20251113&P2=018571&P3=TY421MTAUB&P4=65797c4cae1b1d4a706c19b9e0d68231&P5=73fb607a1702924ab4f50dd50f05d6e9
  • P1 — дата накладної у форматі YYYYMMDD.
  • P2 — номер накладної у верхньому регістрі.
  • P3 — 10-символьний ідентифікатор постачальника.
  • P4 — Хеш1, перші 32 символи SHA-256 у lowercase hex.
  • P5 — Хеш2, перші 32 символи SHA-256 у lowercase hex.
Webhook

Постачальник перевіряє Хеш2 сам

Ключ2 знає тільки система постачальника. У 7A передається вже сформований Хеш2.

POST /7a/invoice
{
  "supplierId": "32AF58B2C7",
  "invoiceNumber": "ІВ0001542",
  "invoiceDate": "2026-08-27",
  "hash2": "32 hex-символи",
  "requestId": "uuid"
}
Тестування

Розберіть URL або згенеруйте QR-код

Локальний інструмент для перевірки параметрів QR під час інтеграції. Тестові ключі не потрапляють у QR-код.

Інструмент для розробників

Перевірте реальний QR-протокол 7A

Вставте готовий URL /Doc з параметрами P1–P5 або заповніть поля вручну та сформуйте сканований QR-код.

або заповніть параметри вручну
0/10
0/10

Перед розрахунком номер накладної переводиться у верхній регістр. Хеші рахуються як SHA-256 від UTF-8 рядка «НОМЕР_YYYYMMDD_КЛЮЧ», після чого беруться перші 32 hex-символи. У P4/P5 вони записуються малими літерами. Ключ1 і Ключ2 у QR не передаються.

Попередній перегляд
Тут з’явиться QR-код

Заповніть поля та натисніть «Згенерувати QR-код».

Повний маршрут

Подвійна незалежна перевірка

Ключ2 ніколи не передається в 7A. Хеш2 транспортується до системи постачальника для незалежної перевірки.

01

Накладна + QR

Постачальник друкує QR на звичайній накладній.

02

Сканування

Покупець сканує QR телефоном або стаціонарним сканером.

03

API 7A

7A перевіряє Hash1 і визначає постачальника.

Hash1 ✓
04

Webhook

7A безпечно звертається до прихованого Webhook постачальника.

Hash2 → постачальнику
05

Готовий документ

JSON повертається в облікову систему покупця.

Почніть інтеграцію з протоколу v1

Повна схема endpoint-ів доступна в OpenAPI.