Посилання та усунення несправностей

Рекомендації щодо інтеграції

View as Markdown

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

Автентифікація та секрети

  • Віддаю перевагу API Key підпису для серверних торгових програм і JWT для дій, керованих користувачами.
  • Зберігати apiSecret в управлінні секретами бекенду. Він відображається лише один раз і ніколи не повинен надсилатися браузеру чи мобільному клієнту.
  • Застосовувати мінімально необхідні API Key дозволи та обмежувати IP-адреси джерела, коли середовище інтеграції підтримує стабільні вихідні адреси.
  • Негайно вимкнути або видалити витік ключа, а потім переглянути журнали запитів перед виданням заміни.

Запит валідації та ідемпотентності

  • Перед розміщенням замовлень запит /v1/public/market/symbols та локально перевіряйте tickSize, stepSize, мінімальну номінальну цінність і максимальну кількість.
  • Генерувати унікальний clientOrderId для кожного запису порядку, щоб запити можна було узгоджувати після розриву.
  • Зберегти оригінальний ідентифікатор, коли результат HTTP невизначений. Запит до існуючого порядку перед створенням запиту на заміну.
  • Розглядати десяткові числа та ціни як рядки або десяткові типи, а не як бінарні значення з плаваючою комою.

Ордер і WebSocket стан

  • Визначити остаточний стан після операцій скасування, скасування всіх або змін із [приватних WebSocket подій] (/developer-api/websocket/private-user-channel) або REST запиту.
  • Розглядати кожне повторне підключення як нову WebSocket сесію та відновлювати всі необхідні підписки.
  • Перевірте безперервність книги замовлень за допомогою endVersion. Якщо з’являється прогалина у версіях, відкидайте локальну книжку і знову підпишіться для нового знімку.
  • Дедуплювати приватні події замовлень і рахунків перед їх застосуванням до балансів, позицій або записів партнерів.

Логування, моніторинг і повторні спроби

  • Ідентифікатор запиту запису, ID замовлення клієнта, HTTP статус, API бізнес-код, затримка та кількість повторних спроб без логування секретів або повних токенів.
  • Повторювати лише операції, задокументовані як безпечні, з використанням обмеженого експоненціального відходу та джиттеру.
  • Сповіщення про невдачі автентифікації, помилки підпису, відповіді на обмеження швидкості, цикли повторного підключення WebSocket , прогалини послідовності та відмінності у звірці порядків.
  • Підтримувати синхронізацію годинників серверів, оскільки автентифікація та підписання залежать від часових позначок.

До виробництва