Первый пример и запрос

Откройте демонстрацию и пройдите шаги операции. Перед каждым действием показано текущее состояние; после него — результат шага и доступное продолжение.

Пример использует вымышленные данные и не требует входа, ключа API или доступа к репозиторию. Он показывает работу интерфейса; ответ реального сервера, сделка или платёж этим примером не подтверждаются.

Чтобы проверить именно серверное решение и повтор запроса, перейдите к тестовому API.

Начните со страницы тестового доступа. Она проверит настроенный API и покажет актуальные срок ключа и ограничения до создания организации.

Ключ показывается один раз и остаётся в памяти страницы. Событие записывается атомарно с решением, аудитом и ответом на повтор. Это объект проверки допустимости: платёж, сделка и внешний webhook этим сценарием не выполняются. После перезагрузки история решения сохраняется на сервере; для нового API-запроса нужен действующий ключ.

Для API-клиента используйте тот же ключ и GET /v1/developer/outbox-events/evt_<decision_id>, подставив decision_id из ответа. Достаточно уже выданного evidence:read. Секрет передаётся только в Authorization; публикация события не подтверждает обработку получателем.

1. 01

   Проверьте доступность среды

   Если создание доступно, прочитайте ограничения и создайте тестовую организацию. Если источник недоступен, запрос не создаётся; можно вернуться к браузерному примеру.

2. 02

   Получите решение

   Выберите ALLOW, REVIEW или DENY и отправьте подготовленный запрос. Параметры, ожидаемый исход и Idempotency-Key подготовлены сервером. Фактический результат появится после ответа.

3. 03

   Проверьте повтор

   Повторите тот же запрос предусмотренной кнопкой. Она сохраняет тело и Idempotency-Key. Сравните ID решения, outcome и признак повтора.

4. 04

   Проверьте конфликт параметров

   После первого ответа нажмите «Проверить конфликт параметров». Страница меняет сумму на одну минимальную единицу и сохраняет прежний ключ. Ожидаемый результат — 409 IDEMPOTENCY_CONFLICT: исходное решение остаётся единственным.

5. 05

   Откройте событие решения

   Нажмите «Открыть событие решения». Тот же ограниченный ключ читает сохранённое событие проверки допустимости. PENDING или PROCESSING означает ожидание публикации; PUBLISHED подтверждает только приём отправителем, а не обработку получателем. QUARANTINED требует проверки очереди оператором.

Этот путь доступен после получения исходников. Репозиторий приватный; публичной автоматической выдачи доступа нет. Если доступ не предоставлен, начните с браузерного примера или проверьте тестовый API.

В доступной вам копии проекта нужны Docker CLI, Compose v2 и работающий Docker runtime. Команды выполняются из корня репозитория. Основной HTTP-порт — 8080; остальные занятые порты и требования указаны в README этой копии.

Следующие команды уже приведены в README и Makefile проекта. Если ваш Docker runtime требует context, используйте настроенный context; для целей Makefile предусмотрен DOCKER_CONTEXT.

1. 01

   Дождитесь готовности

   Продолжайте после успешного запуска и проверки /readyz. Эта проверка подтверждает доступ к хранилищу решений; она не проверяет все внешние сервисы.

2. 02

   Подготовьте локальный ключ

   Используйте настроенное значение CERTARAIL_API_KEY из своей локальной среды. В cURL ниже замените <sandbox-bearer> этим ключом. Исходный пример использует tenant sandbox-bank; он должен совпадать с разрешённым сервером tenant.

3. 03

   Отправьте пример и прочитайте ответ

   Проверьте HTTP-статус, ID решения, исход и причины. ALLOW разрешает следующий этап проверки; сам по себе он не подтверждает исполнение.

docker compose config --quiet
docker compose up --build --detach --wait
docker compose ps
make compose-ready

После готовности локального контура замените placeholder ключа и отправьте пример. Адрес localhost:8080 относится к вашему компьютеру. Для удалённой тестовой среды используйте подготовленный запрос на странице тестового доступа.

curl -X POST http://localhost:8080/v1/eligibility/evaluations \
  -H "Authorization: Bearer <sandbox-bearer>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: bank-order-000001" \
  -d '{
    "request_id": "bank-order-000001",
    "tenant_id": "sandbox-bank",
    "facts_observed_at": "2026-08-24T18:20:00Z",
    "operation": "BUY",
    "asset_code": "DEMO-BTC",
    "amount": { "currency": "RUB", "minor_units": 25000000 },
    "client": {
      "subject_ref": "cust_7fd2",
      "facts_version": "kyc-443",
      "residency": "RU",
      "investor_category": "RETAIL",
      "kyc_status": "VERIFIED",
      "screening_status": "CLEAR",
      "knowledge_test": {
        "passed": true,
        "passed_at": "2026-08-01T00:00:00Z",
        "valid_until": "2027-08-01T00:00:00Z"
      },
      "risk_disclosure": {
        "accepted": true,
        "version": "sandbox-risk-v1",
        "accepted_at": "2026-08-24T18:15:00Z"
      },
      "annual_volume": { "currency": "RUB", "minor_units": 10000000 }
    },
    "intermediary": { "kind": "BROKER", "regulated": true }
  }'

HTTP 200 означает, что API оценил запрос. В примере зафиксирована дата facts_observed_at. Когда она старше допустимого срока, ожидаем REVIEW с причиной FACTS_SNAPSHOT_STALE: запрос обработан, но сведения требуют обновления. Для проверки свежих учебных фактов измените эту дату на текущее время UTC и используйте новый ключ запроса. Не меняйте исходный запрос для повтора после неизвестного результата.

• Тот же Idempotency-Key и неизменное тело возвращают сохранённый результат. Изменённое тело с тем же ключом должно дать конфликт 409.
• При таймауте результат остаётся неизвестным. Сохраните исходные параметры и сверяйте результат; не создавайте новое поручение для обхода неопределённости.
• Тестовое решение, повтор и история не подтверждают платёж, покупку актива или внешнюю доставку события.

{
  "decision": {
    "outcome": "REVIEW",
    "enforceable": false,
    "policy_mode": "SANDBOX",
    "checks": [
      {
        "id": "FACTS_SNAPSHOT_STALE",
        "status": "REVIEW"
      }
    ]
  }
}