📶 Rate-limit

За последние 7 дней время ночного экспорта в DWH сократилось на 38% после добавления batch-стриминга и backpressure: backend шлёт POST /dwh/v1/events/batch с Authorization Bearer и X-Request-Id=dwh_9a7 {cursor, events[500]} → 202 {jobId}; воркер по jobId выполняет GET /dwh/v1/jobs/{jobId}/status → succeeded; если 429, повторяет POST с тем же X-Request-Id и cursor. Итог: выгрузка стабильна и без дублей.
Look API

📉 Транзакции

За последние 7 дней число “двойных” списаний в проде снизилось на 34% после внедрения outbox и подтверждения платежа через webhook. Request: POST /bank/v1/transfers с Authorization Bearer и X-Idempotency-Key=trn_91c2 {orderId, amount, currency, customerId} → 201 {transferId}; далее PSP шлёт POST /payments/v1/webhooks/transfer-confirm с X-Request-Id=psp_2a8f {transferId, status} → 200 после записи в outbox по transferId. Итог: меньше инцидентов и стабильнее сверка.
Look API

💳 OAuth
За последние 7 дней доля отклонённых лимитных операций в fintech снизилась на 19% после внедрения короткоживущих токенов и refresh-логики: backend делает POST /crm/v1/oauth/token с Basic client_credentials → 200 {access_token, expires_in}, затем POST /crm/v1/limits/lock с Authorization Bearer access_token и X-Idempotency-Key=lim_3b7a {customerId, amount, currency, orderId} → 201 {lockId}; если в ответе 401, повторяет lock после refresh. Итог: лимиты встают предсказуемо даже при смене токенов.
Look API

🧾 Выдача
За последние 7 дней доля “подвисших” заявок на кредит снизилась на 28% благодаря автообновлению статусов через webhook. PSP присылает POST /credit/v1/webhooks/decision с HMAC-Signature и X-Request-Id=crd_88f1 {applicationId, decision, score, decidedAt} → 202 {jobId}; воркер вызывает POST /crm/v1/applications/{applicationId}/status {status, providerDecisionId} → 200 и пишет in/outbox по jobId. Итог: статусы не теряются и не дублируются.
Look API

📦 Автоматизация
За последние 7 дней доля ошибочных сопоставлений клиентов с ERP снизилась на 22% после async-переотправки событий. Бэкенд получает POST /crm/v1/webhooks/customer-updated с X-Signature и X-Request-Id=crm_6f4a {externalId,email,updatedAt} → 202 {jobId}; воркер кладёт payload в очередь и делает POST /erp/v1/customers/sync {externalId, email} → 200. Ошибки 409 приводят к повтору по jobId. Итог: синхронизация без потерь и дублей.
Look API

🧩 Сбоев интеграции с ERP за 7 дней стало на 26% меньше после перехода на контрактные запросы с метриками в реальном времени. Backend вызывает GET /erp/v2/invoices/{invoiceId} с X-Request-Id=inv_7c4a и Authorization, получает 200 {status, total, updatedAt}. Если статус “POSTED”, backend делает POST /warehouse/v1/events {"type":"invoice_posted","invoiceId","at":updatedAt} → 202. Логи и tracing по X-Request-Id сразу показывают причину таймаутов. Итог: данные доходят до склада без “немых” провалов.
Look API

💳 Транзакции
За последние 7 дней число отмен в платежном цикле снизилось на 21% после перехода на подтверждение по webhook с идемпотентным ключом. Backend вызывает POST /psp/v1/charges с Authorization Bearer и X-Idempotency-Key=chg_3f21 {orderId, amount, currency} → 201 {chargeId}. PSP присылает POST /payments/v1/webhooks/charge-confirm с HMAC и X-Request-Id=psp_7a9c {chargeId, status} → backend пишет в outbox по chargeId и отвечает 200; повтор webhook не меняет состояние. Итог: меньше расхождений статусов в проде.
Look API

🧾 Финтех-авизо
За последние 7 дней число просроченных сверок по реестру платежей в одном банке сократилось на 31% после переноса на инкрементальный обмен. Backend раз в 5 минут делает GET /gov/payments/v3/registry/changes?since=2026-09-08T00:00:00Z с API key → 200 {items[{txnId,status,amount}], nextSince}; затем PUT /ledger/v1/tx/{txnId} {status} → 200 и запись checkpoint в storage, чтобы повторы не меняли уже учтённые статусы. Итог: реестр сходится без ручных “догонялок”.
Look API

🧾 Риск-скоринг
За последние 7 дней время подтверждения KYC сократилось на 37% после перехода на предзапрос статуса до вызова скорингового API. Backend отправляет POST /kyc/v1/check с Authorization Bearer и body {subjectId, docType} → 200 {riskScore, status}; если status=need_review, ставит задачу в очередь и запрашивает GET /scoring/v1/result/{jobId} → 200 {decision}. Итог: решения приходят быстрее без ручных сверок.
Look API

💳 Платежи
За последние 7 дней доля “двоек” в выгрузке из банка снизилась на 34% после сверки статуса транзакции. Backend по событию отправляет POST /psp/v1/charges с Authorization Bearer и X-Idempotency-Key=chg_9f12 {orderId, amount} → 201 {chargeId}; PSP шлёт POST /payments/v1/webhooks/charge-confirm с HMAC {chargeId,status}. Backend пишет chargeId в outbox и возвращает 200, повтор webhook не меняет ledger. Итог: меньше расхождений и ручных разборов.
Look API

🧊 Шардирование
За последние 7 дней доля таймаутов при обмене статусами между микросервисами снизилась на 26% после перехода на очереди событий и идемпотентные ключи. Order-service шлёт POST /events/v1/order.shipped с X-Idempotency-Key=ord_7c1 {orderId, shipAt} → 202; consumer отвечает PATCH /shipping/v1/orders/{orderId} {"status":"shipped"} → 200 и сохраняет processed_at в outbox, повтор не меняет запись. Итог: меньше дублей и быстрее согласование статусов.
Look API

📦 Инвойсы
За последние 7 дней доля “зависших” согласований в закупках снизилась на 28% после автоматической сверки документов. Сервис получает GET /gov/tenders/v1/contractors/{inn}/status?from=2026-09-12 с API key → 200 {contracts:[{id,ver,stage,updatedAt}]}; если stage="signed", отправляет POST /erp/v2/purchase-invoices {"contractId":id,"version":ver} → 201 {invoiceId} и сохраняет checksum, чтобы повторы не меняли проводки. Итог: согласования проходят быстрее и без ручных расхождений.
Look API

🛰️ Госреестры

За последние 7 дней доля отклонённых выгрузок из налогового реестра снизилась на 18% после синхронизации по инкрементальным изменениям: backend шлёт GET /gov/tax/v2/registry/changes?since=2026-09-13T00:00:00Z с API key → 200 {items, nextSince}; затем POST /data-exchange/v1/registry/events {"inn","txnId","payload"} → 202 и пишет checkpoint, чтобы повторы не перезаписывали данные. Итог: реестр сходится быстрее и без расхождений.
Look API

📈 Автоматизация

За последние 7 дней доля ошибок в сверке статусов с платежным PSP упала на 19% после внедрения подтверждения через webhook с идемпотентностью. Backend шлёт POST /psp/v1/charges с Authorization Bearer и X-Idempotency-Key=chg_7dd1 {orderId, amount} → 201 {chargeId}; PSP вызывает POST /payments/v1/webhooks/charge-confirm с HMAC {chargeId,status}. Backend сохраняет chargeId в outbox и отвечает 200, повтор не меняет ledger. Итог: меньше ручных разборов и расхождений.
Look API

💳 Платежи

За последние 7 дней доля возвратов по карточным платежам выросла на 6% после того, как PSP начал отклонять несоответствие сумм; backend чинит это через идемпотентный запрос: POST /psp/v1/refunds с Authorization Bearer и X-Idempotency-Key=rf_82a1 {chargeId, amount, reason} → 201 {refundId}; PSP шлёт webhook POST /payments/v1/webhooks/refund-result с HMAC {refundId,status}. Итог: меньше дублей и быстрые разборы расхождений.
Look API

📊 Мониторинг

За последние 7 дней доля инцидентов “несоответствие схемы” в витрине данных выросла на 12% после того, как поменялась версия гос-выгрузки. Backend по таймеру шлёт GET /gov/supply/v3/documents/123?version=2026-09-01 с API key → 200 {doc, schemaVersion}, валидирует, если schemaVersion!=ожидаемой — делает POST /data-exchange/v1/errors {"documentId":"123","code":"SCHEMA_MISMATCH"} → 202 и пишет метрику в мониторинг через PUT /observability/v1/alerts/supply → 200. Итог: меньше падений витрины при изменениях внешних форматов.
Look API