API klíče

Poslední aktualizace: 20. srpna 2026

API klíče poskytují automatizovaným systémům, obchodním botům, operačním skriptům, reportovacím pipeline a FIX obchodním relacím programový přístup k účtům vaší organizace. Tento článek popisuje model oprávnění API klíčů, způsob mapování klíčů na účty, uplatňování správy organizace na operace zahájené klíčem a správu samotných klíčů.

API klíče nejsou členové s přihlašovacími údaji. Mají vlastní, jednodušší model oprávnění:

Člen

Klíč API

Ověření

Individuální přihlášení pomocí 2FA

Přihlašovací údaje API klíče

Přístup k uživatelskému rozhraní

Ano

Ne, pouze API

Model oprávnění

Workflow Profile + Account Roles

Oprávnění API klíče platí pro všechny vybrané účty

Variabilita na úrovni účtu

Ano, role mohou přidělovat různá oprávnění na různých účtech

Ne, oprávnění klíče se vztahují jednotně na všechny vybrané účty

Může zahajovat žádosti o výběr a převod

Ano, je-li to povoleno

Ano, je-li to povoleno

Může schvalovat žádosti

Ano, kromě vlastních

Nikdy

Administrativní workflow

Ano, podle jejich Workflow Profile

Nikdy

Oba modely jsou záměrně oddělené. Členové mají role, profily a různá oprávnění pro jednotlivé účty, protože lidé časem přebírají různorodé odpovědnosti. Klíče pracují s plochým modelem: rozsah oprávnění a přiřazené účty. Automatizace má být úzce vymezená, jednotná a snadno auditovatelná.

API klíč kombinuje dvě nastavení: co může dělat (jeho oprávnění) a kde (jeho účty).

Oprávnění

Skupina

Oprávnění

Co umožňuje

Prostředky

Dotaz na prostředky

Zobrazení zůstatků a stavu financování

Vložit

Generování adres pro vklady a zobrazení historie vkladů

Vybrat

Zahájení žádostí o výběr (viz „Správa a API klíče")

Earn

Alokace a zrušení alokace produktů Earn

Objednávky

Dotaz na otevřené příkazy

Zobrazení otevřených příkazů a aktivních obchodů

Dotaz na uzavřené příkazy

Zobrazení historických příkazů a dokončených obchodů

Vytvořit a upravit objednávky

Zadávání a úprava příkazů

Zrušení a uzavření příkazů

Zrušení otevřených příkazů a uzavření pozic

Adresy

Přidat adresu pro výběr

Zahájení žádostí o přidání adres na whitelist

Aktualizujte adresu pro výběr

Zahájení žádostí o změnu adres na whitelistu

Data

Dotaz na účetní knihu

Zobrazení historie transakcí a účetní knihy

Exportovat data

Export dat účtu pro účely reportingu a rekonciliace

Mapování účtů

Každý klíč je přiřazen k jednomu nebo více účtům – výběr se provede při vytvoření klíče a lze ho později upravit. Oprávnění klíče se vztahují jednotně na všechny vybrané účty:

  • Klíč s oprávněními Dotaz na prostředky a Vytvořit a upravit příkazy na dvou vybraných účtech může číst zůstatky a obchodovat na obou – nic jiného neprovede.
  • V rámci jednoho klíče nelze nastavit různá oprávnění pro různé účty. Pokud vaše automatizace potřebuje obchodovat na jednom účtu a z druhého pouze číst data, použijte dva klíče. Rozsah možného dopadu každého klíče tak zůstane přehledný na první pohled.

Výběr konkrétního účtu

Soukromé API požadavky pracují s primárním účtem organizace, pokud parametr account_id není uveden:

bash

Bash

POST /0/private/AddOrder

Chcete-li pracovat s konkrétním účtem, předejte account_id jako parametr dotazu v URL:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Předávejte ho v URL, nikoli v těle požadavku. Explicitně zadaný parametr account_id má přednost před výchozím primárním účtem. Nerozšiřuje mapování účtů ani oprávnění klíče. Pokud klíč nemá oprávnění pro vybraný účet, požadavek je odmítnut.

Konektivita FIX

Klíče s oprávněními pro příkazy podporují konektivitu FIX pro spotové obchodování vedle REST a WebSocket API. Relace FIX přebírá stejná oprávnění a mapování účtů jako příslušný klíč: obchoduje pouze na vybraných účtech klíče a v rámci jeho oprávnění. Firmy s tokem příkazů přes FIX zpravidla přiřazují každé relaci samostatný klíč omezený na účty daného obchodního stolu.

Poznámka:

Obchodování přes WebSocket na jiných účtech než na hlavním účtu zatím API klíče nepodporují – tato funkce je prozatím dostupná pouze vlastníkům organizace. Automatizovaný tok příkazů na dalších účtech by měl využívat REST nebo FIX. Viz Dostupnost a omezení.

Nastavení zabezpečení

Nastavení

Popis

Vypršení platnosti klíče

Volitelné datum, po jehož uplynutí klíč přestane fungovat

Datum začátku / konce dotazu

Omezení datových dotazů na zadaný časový rozsah

WebSocket připojení

Povolte nebo zakažte streamování v reálném čase

Vlastní okno jednorázového klíče

Nastavení ochrany proti replay útokům pro vysokofrekvenční provoz

Omezení IP adres

Omezte použití klíče na konkrétní IP adresy nebo rozsahy CIDR

Tip:

Každému klíči přidělte nejužší oprávnění, nejmenší počet účtů a nejpřísnější omezení IP adres, která mu umožní splnit jeho účel. Používejte samostatné klíče pro každý systém – jeden pro obchodní bot, jeden pro reporting – a odvolávejte je cíleně.

Správa organizace se vztahuje jak na to, co klíče dělají, tak na způsob jejich správy.

Co klíče dělají

Pravidlo dvou kategorií platí pro klíče stejným způsobem jako pro členy:

  • Přímé operace se provádějí okamžitě. Obchodování, Earn, dotazy na zůstatky, dotazy na účetní knihu a exporty dat se dokončí okamžitě, v rámci oprávnění a účtů klíče.
  • Řízené operace vytvářejí žádosti. Žádost o výběr nebo změnu adresy spuštěná klíčem vstupuje do stejného procesu jako žádost spuštěná členem: zásady pracovního postupu rozhodnou, zda se dokončí okamžitě, nebo čeká ve frontě schválení.

Klíč může řízené žádosti pouze zahajovat. Klíče nikdy nemají oprávnění ke schvalování – princip oddělení povinností vyžaduje, aby každou žádost schválil člen, a skript ho v tomto úsudku nemůže nahradit. Pokud zásady žádosti o výběr vyžadují dvě schválení, výběr iniciovaný klíčem čeká na schválení dvěma členy – stejně jako výběr iniciovaný členem.

Úspěšné volání neznamená dokončený výběr

Nastavte svou automatizaci s ohledem na tuto asynchronnost. WithdrawFunds vrací approval_request_id spolu s refid:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • refid potvrzuje, že žádost existuje, nikoli že se prostředky přesunuly. Částka je na zdrojovém účtu blokována v okamžiku odeslání a vypořádá se teprve po schválení žádosti. Viz Prostředky jsou blokovány při odeslání.
  • approval_request_id je identifikátor schválení, na které výběr čeká. Uložte ho spolu s vlastním záznamem o výběru.
  • Výběry čekající na schválení se ve WithdrawStatus nezobrazují. Žádost zamítnutá nebo taková, které vyprší platnost, nezanechá žádný záznam o výběru – absence záznamu v WithdrawStatus tedy nikdy neznamená, že výběr nebyl odeslán.

Automatizace, která považuje refid za potvrzení dokončení, bude hlásit výběry jako vypořádané, i když čekají ve frontě schválení. Reconciliace vyvozující „není v WithdrawStatus, tedy nikdy odesláno" bude chybná pro čekající i zamítnuté žádosti.

Klíče nemají přístup ani ke správě interních procesů organizace. Správa přístupu členů týmu, API klíčů, účtů, adres (s výjimkou iniciování žádostí o přidání adresy) a zásad je vyhrazena pouze členům (Members).

Správa klíčů

Vytváření, úpravy a odvolávání API klíčů jsou řízené operace prováděné prostřednictvím vyhrazeného procesu Manage API Keys, který je oddělený od Manage Team & Access. Toto oddělení je důležité ze dvou hledisek:

  • Různí správci. Provoznímu inženýrovi můžete umožnit správu klíčů, aniž by měl možnost měnit přístup členů (Members), a naopak.
  • Různé zásady. Správa klíčů může mít vlastní požadavky na schvalování. Mnoho organizací vyžaduje nezávislé schválení pro vytvoření nebo úpravu klíče (nové přihlašovací údaje představují novou cestu k účtům), přičemž odvolání klíče zůstává rychlé.
  1. Přejděte na API klíče a vyberte Vytvořit klíč.
  2. Pojmenujte klíč podle jeho účelu – systému, který obsluhuje, a funkce, kterou plní – aby bylo jeho použití zřejmé při kontrolách i bezpečnostních incidentech.
  3. Vyberte oprávnění klíče.
  4. Vyberte účty, na které se bude klíč vztahovat. Oprávnění se vztahují na všechny vybrané účty jednotně.
  5. Nakonfigurujte nastavení zabezpečení: vypršení platnosti, omezení IP adres, okno nonce.
  6. Zkontrolujte nastavení a potvrďte. Pokud zásady správy API klíčů vyžadují schválení, klíč bude vydán až po udělení potřebných schválení.
Upozornění:

Tajný klíč se zobrazí pouze jednou – při vytvoření. Uložte jej bezpečně ještě před opuštěním obrazovky – pozdější zobrazení není možné.

Úprava oprávnění nebo účtů klíče a jeho odvolání procházejí stejným schvalovacím postupem.

Řešení problémů

Volání vytvořilo žádost o výběr a zásady žádostí o výběr ji drží ke schválení. Zkontrolujte stránku Žádosti – žádost se tam zobrazí s klíčem jako iniciátorem a čeká na schválení příslušnými členy. Správa funguje tak, jak má: automatizace navrhuje, lidé schvalují.

Částka je na zdrojovém účtu zablokována po dobu čekání na schválení – je tak již vyhrazena pro výběr. Sledujte žádost pomocí hodnoty approval_request_id vrácené spolu s voláním.

Účet, u kterého dochází k chybě, není součástí mapování účtů klíče. Klíč pracuje pouze s vybranými účty. Upravte klíč a přidejte příslušný účet – mějte na paměti, že se na něj vztáhne celá sada oprávnění klíče, protože klíče nepodporují různá oprávnění pro jednotlivé účty. Pokud je to příliš široký přístup, vytvořte druhý klíč s rozsahem omezeným na nový účet.

Jeden klíč nemůže mít různá oprávnění pro různé účty. Vytvořte dva klíče: obchodní klíč přiřazený k účtu A a klíč pouze pro čtení přiřazený k účtu B. Užší klíče se navíc snadněji auditují a jejich odvolání je bezpečnější.

Pracovní postup Správa klíčů API pravděpodobně vyžaduje schválení a žádost stále čeká na vyřízení. Klíč je vydán a jeho tajný kód zobrazen až po shromáždění všech požadovaných schválení. Zkontrolujte stav žádosti na stránce Žádosti.

Ne. Schválení vždy vyžaduje reálného člena týmu. Jde o systémové pravidlo, nikoli o konfigurovatelnou zásadu – právě to dává vícestranným schválením smysl ve chvíli, kdy automatizace iniciuje pohyb prostředků.

Související články