Помилки API

Використовуйте ту поверхню відповіді, яка відповідає запиту:

• Збій HTTP: JSON-відповідь 4xx або 5xx містить стабільне поле code і діагностичне поле message.
• Результат ордера: відповідь на ордер з HTTP 200 все одно може означати відхилення. Перевіряйте її status і reason.
• Відповідь JSON-RPC: ендпоінти JSON-RPC зберігають числові значення error.code всередині відповіді HTTP 200.

Відповіді з помилками HTTP

Кожна JSON-відповідь з помилкою HTTP 4xx і 5xx, згенерована API, містить:

{
  "error": "existing endpoint value, when present",
  "code": "invalid_field",
  "message": "price must be greater than zero"
}

code є програмним контрактом. Розгалужуйте логіку за цим ідентифікатором у нижньому регістрі та безпечно обробляйте невідомі майбутні значення. message є діагностичним текстом. Показуйте або логуйте його, але не парсіть.

error є збереженим застарілим полем. Деякі ендпоінти вже повертають його і продовжуватимуть це робити, але воно непрозоре і не є новим контрактом. Наявні поля, специфічні для ендпоінтів, як-от деталі готовності та Retry-After, залишаються.

Відповіді HEAD не мають тіла. Використовуйте їхній HTTP-статус як зазвичай; Hypercall не додає окремого заголовка з кодом помилки.

Попередня перевірка виведення

Виведення USDC з доставкою в Core перевіряють активацію одержувача та сумісність переказу, перш ніж прийняти нове виведення. Обробляйте withdrawal_destination_inactive і withdrawal_destination_mode_unsupported як помилки адреси призначення. withdrawal_preflight_unavailable означає, що перевірка тимчасово недоступна. withdrawal_source_unavailable вимагає, щоб сервіс відновив сумісний рахунок-відправник або маршрут.

Ці помилки не створюють нового списання для виведення. Раніше прийнятий запит зберігає свій поточний статус. Успішна попередня перевірка не гарантує доставки; продовжуйте відстежувати статус виконання виведення. Виведення лише в EVM не потребують відповідності рахунку HyperCore.

Режим рахунку для портфельної маржі

Портфельна маржа оцінює Account за його капіталом у HyperCore, який HyperCore публікує лише для Account у режимі unifiedAccount.

• POST /margin-mode з portfolio повертає 400 pm_account_not_unified, коли Account перебуває в іншому режимі. Підпишіть директиву hl_set_abstraction з абстракцією unifiedAccount, дочекайтеся підтвердження від HyperCore, потім повторіть запит.
• GET /portfolio для Account з портфельною маржею без актуального капіталу в HyperCore повертає 409 pm_account_not_unified, коли HyperCore ніколи не публікував капітал для цього Account і повідомляє, що він в іншому режимі. В інших випадках повертається 503 pm_account_equity_pending, доки актуальний уніфікований знімок не надійде до рушія; коли збережений капітал застарів і HyperCore повідомляє про інший режим, повідомлення називає цей режим. Повторюйте запит після pm_account_equity_pending невдовзі та знову ввімкніть уніфікований режим, якщо повідомлення вказує, що Account з нього вийшов.
• account_abstraction_unavailable (503) означає, що режим рахунку HyperCore не вдалося прочитати. Невдовзі повторіть запит.

Розміри ніг RFQ

Розміри контрактів виконуються в одиницях 0.000001. POST /rfq/request відхиляє розмір ноги, що має більше шести десяткових знаків, з HTTP 400; повідомлення вказує найбільший виконуваний розмір, округлений униз. Hypercall не округлює розмір за вас, оскільки тейкер підписує точні розміри ніг. Округліть униз перед підписанням і надішліть повторно.

Причини відмови в попередній перевірці котирувань RFQ

Котирування маркетмейкера, відхилене під час попередньої перевірки, містить короткий код причини. margin_rejected означає, що рахунок маркетмейкера не пройшов перевірку маржі для пакета. pricing_unavailable означає, що майданчик не зміг оцінити пакет, наприклад через відсутність поверхні імпліцитної волатильності або референсної ціни; це не рішення щодо маржі, і нове котирування може бути успішним, щойно ціноутворення відновиться.

Відхилення ордерів

Ордер може повернути HTTP 200 з результатом виконання, що містить відхилення:

{
  "status": "REJECTED",
  "reason": "Insufficient margin: required=1500.00, equity=1200.00, shortfall=300.00, current_consumed_initial_margin=900.00, incremental_order_initial_margin=600.00, current_consumed_maintenance_margin=500.00, incremental_order_maintenance_margin=250.00"
}

reason є пояснювальним текстом, а не стабільним кодом. Він може містити поточні значення та змінюватися з розвитком валідації. За недостатньої портфельної маржі required є загальною початковою маржею після ордера, тоді як поля current_consumed_* і incremental_order_* відокремлюють наявне використання від нового ордера. Використовуйте status, щоб визначити відхилений ордер, потім показуйте або логуйте reason. Стабільний контракт кодів відхилення ордерів був би окремою роботою над протоколом і SDK.

Для ордерів на перпи з портфельною маржею open_orders_initial_margin є додатковою IM від найгіршого незалежно обраного стану, незаповненого або з повним заповненням за лімітною ціною, серед активних ордерів. Ордер може бути прийнято, коли рахунок перебуває нижче IM, лише якщо його додавання не збільшує цю оболонку або відповідну вимогу до підтримуючої маржі за найгіршого заповнення. Відкриті ордери, як і раніше, не змінюють опубліковану MM позиції. Клієнти не повинні робити висновок, що прийняття означає повне фінансування поточного рахунку, і не повинні парсити діагностичний reason, щоб відрізнити фінансований допуск від допуску, що не погіршує стан.

Помилки JSON-RPC

GET /orderbook зберігає відповідь у стилі JSON-RPC для відсутнього інструмента з HTTP 200:

{
  "jsonrpc": "2.0",
  "error": {
    "code": 13020,
    "message": "not_found",
    "data": {"object": "instrument_name", "value": "BTC-20200101-1-C"}
  },
  "testnet": false,
  "usDiff": 1,
  "usIn": 1791273938274109,
  "usOut": 1791273938274109
}

Розгалужуйте логіку за числовим error.code. Специфічні для RSM коди JSON-RPC не входять до стандартного публічного HTTP-каталогу.

Публічний каталог кодів помилок

Цей каталог із пошуком згенеровано з розширення info.x-hypercall-error-codes у публічному документі OpenAPI. Він містить лише HTTP-коди для споживачів і завжди активні коди JSON-RPC.

Loading API error catalog…

Контрольний список обробки

• HTTP-клієнти: розгалужуйте логіку за code, зберігайте HTTP-статус і враховуйте Retry-After, якщо він присутній.
• Клієнти ордерів: розглядайте status: "REJECTED" як результат виконання, навіть якщо HTTP-запит був успішним.
• Клієнти JSON-RPC: розгалужуйте логіку за числовим error.code для нативного протоколу ендпоінта.
• Усі клієнти: майте безпечний запасний варіант для невідомих майбутніх кодів і ніколи не парсіть діагностичні повідомлення.