Розробка

Store API та webhooks

Як працюють ключі магазину, scopes, ідемпотентність і versioned provider webhooks.

0. Людський довідник замість сирого OpenAPI JSON

На сторінці /platform/docs/api-reference доступний пошук за точними методами, шляхами, scopes, параметрами та DTO зовнішнього Store API.

Файл openapi.json лишається machine-readable release artifact для генераторів і перевірок. Він не призначений для послідовного читання людиною.

Компанію створює авторизований користувач у бізнес-кабінеті. Store API key працює лише в межах уже створеного магазину й не дає адміністративних прав.

1. API-ключ завжди належить конкретному магазину

Store API використовує схему Authorization: Api-Key. Ключ має tenant, store, surface та дозволені scopes.

Provider tokens і повне значення Store API key не повертаються у браузер після створення.

GET /api/v1/external/stores/{store_id}/context HTTP/1.1
Authorization: Api-Key <store-api-key>
Accept: application/json

2. Повтори mutation-запитів контролюються контрактом

Checkout submissions, quotes і payment sessions вимагають Idempotency-Key довжиною 16–128 символів.

Повтор із тим самим ключем не повинен створювати другу бізнес-операцію. Точний response дивіться у generated OpenAPI для поточної release candidate.

POST /api/v1/external/stores/{store_id}/checkout/submissions HTTP/1.1
Authorization: Api-Key <store-api-key>
Idempotency-Key: <stable-operation-key>
Content-Type: application/json

3. Webhook — це окремий versioned контракт

SendPulse, KeyCRM та інші provider webhooks мають власні маршрути, перевірку connection і правила повторної доставки.

Не існує одного універсального підпису для всіх провайдерів. Тип перевірки, token path і допустимі події зафіксовані у API reference.

До всіх інструкцій Увійти до робочого простору