API keys geven geautomatiseerde systemen, tradingbots, operationele scripts, rapportagepipelines en FIX-handelssessies programmatische toegang tot de accounts van je Organisatie. Dit artikel beschrijft het permissiemodel voor API keys, hoe keys aan accounts worden gekoppeld, hoe het bestuur van de Organisatie van toepassing is op door keys geïnitieerde bewerkingen, en hoe het beheer van keys zelf wordt geregeld.
API keys zijn geen Members met inloggegevens. Ze hebben een eigen, eenvoudiger permissiemodel:
Lid | API-sleutel | |
|---|---|---|
Verificatie | Individuele aanmelding met 2FA | API key-inloggegevens |
UI-toegang | Ja | Nee, alleen via API |
Permissiemodel | Workflowprofiel + accountrollen | API key-permissies gelden voor geselecteerde accounts |
Variatie per account | Ja, rollen kunnen verschillende permissies verlenen op verschillende accounts | Nee, de permissies van de key gelden uniform voor alle geselecteerde accounts |
Kan opname- en overboekingsverzoeken starten | Ja, indien toegestaan | Ja, indien toegestaan |
Kan verzoeken goedkeuren | Ja, behalve eigen verzoeken | Nooit |
Administratieve workflows | Ja, op basis van hun workflowprofiel | Nooit |
De twee modellen zijn bewust gescheiden. Members krijgen rollen, profielen en accountspecifieke rechten, omdat mensen uiteenlopende verantwoordelijkheden hebben. Keys krijgen een plat scope-plus-accounts-model, omdat automatisering beperkt, uniform en in één oogopslag controleerbaar moet zijn.
Een API key combineert twee keuzes: wat hij mag doen (de permissies) en waar (de accounts).
Toestemmingen
Groep | Rechten | Wat het mogelijk maakt |
|---|---|---|
Middelen | Geld opvragen | Tegoeden en financieringsstatus bekijken |
Storten | Stortingsadressen genereren en stortingsgeschiedenis bekijken | |
Opnemen | Opnameverzoeken starten (zie "Bestuur en API Keys") | |
Earn | Earn-producten toewijzen en onttrekken | |
Orders | Openstaande orders opvragen | Openstaande orders en actieve trades bekijken |
Gesloten orders opvragen | Historische orders en afgeronde trades bekijken | |
Orders aanmaken en wijzigen | Orders plaatsen en wijzigen | |
Orders annuleren en sluiten | Openstaande orders annuleren en posities sluiten | |
Adressen | Opnameadressen toevoegen | Verzoeken indienen om gewhiteliste adressen toe te voegen |
Opnameadres bijwerken | Verzoeken indienen om gewhiteliste adressen te wijzigen | |
Data | Grootboek opvragen | Transactie- en grootboekgeschiedenis bekijken |
Data exporteren | Accountgegevens exporteren voor rapportage en reconciliatie |
Account mapping
Elke Key is gekoppeld aan een of meer Accounts, gekozen bij aanmaak en later aanpasbaar. De rechten van de Key gelden voor elk geselecteerd Account:
FIX-connectiviteit
Keys met orderrechten ondersteunen FIX-connectiviteit voor Spot-trading, naast de REST- en WebSocket-API's. Een FIX-sessie heeft dezelfde rechten en Account-koppeling als de bijbehorende Key: er wordt alleen getraded op de geselecteerde Accounts van die Key, binnen de toegewezen rechten. Bedrijven met FIX-orderflow reserveren doorgaans één Key per sessie, afgestemd op de Accounts van die desk.
WebSocket-trading op andere Accounts dan het hoofdaccount is nog niet beschikbaar voor API Keys — dit blijft voorlopig voorbehouden aan Owners. Gebruik REST of FIX voor geautomatiseerde orderflow op aanvullende Accounts. Zie Beschikbaarheid en beperkingen.
Beveiligingsinstellingen
Instelling | Beschrijving |
|---|---|
Sleutel vervaldatum | Optionele datum waarna de Key niet meer werkt |
Startdatum / einddatum query | Beperk dataquery's tot een datumbereik |
WebSocket-verbindingen | Realtime streaming in- of uitschakelen |
Aangepaste nonce-periode | Afstemming van replaybeveiliging voor hoogfrequent gebruik |
IP-beperkingen | Beperk het gebruik van de Key tot specifieke IP-adressen of CIDR-reeksen |
Geef elke Key de minimale rechten, zo weinig mogelijk Accounts en de strengste IP-beperkingen die nodig zijn om zijn taak uit te voeren. Gebruik aparte Keys per systeem – één voor de Tradingbot, één voor rapportage – zodat je intrekkingen altijd gericht kunt uitvoeren.
Het Bestuur van de Organisatie bepaalt wat keys mogen doen en hoe keys worden beheerd.
Wat keys doen
De tweecategorieregel voor Members geldt op dezelfde manier voor keys:
Een key kan uitsluitend bestuurde verzoeken indienen. Keys hebben nooit de Goedkeuren-bevoegdheid: functiescheiding vereist een menselijke Member voor elke goedkeuring. Een script kan dat oordeel niet vervangen. Als het Opnameverzoekbeleid twee goedkeuringen vereist, wacht een door een key gestart opnameverzoek op twee Members – precies zoals een door een Member gestart verzoek dat zou doen.
Stem je automatisering af op die asynchronie: een geslaagde API-aanroep betekent dat het verzoek is aangemaakt, niet dat tegoeden zijn overgeboekt. Volg het verzoek tot het is afgerond, en houd rekening met de huidige beperking dat een openstaand verzoek geen tegoeden reserveert. Als het tegoed tijdens de beoordeling wijzigt, mislukt het goedgekeurde verzoek en moet het opnieuw worden ingediend. Zie Tegoeden beschikbaar houden tot goedkeuring.
Keys hebben ook geen toegang tot administratieve workflows. Het beheer van teamtoegang, API keys, accounts, adressen (buiten het starten van adresverzoeken) en beleidsregels is voorbehouden aan Members.
Hoe keys worden beheerd
Het aanmaken, bewerken en intrekken van API keys is een bestuurde bewerking binnen de speciale Manage API Keys-workflow, los van Manage Team & Access. De scheiding is om twee redenen belangrijk:
De secret van de key wordt eenmalig getoond, direct na aanmaak. Sla de secret veilig op voordat je het scherm verlaat – hij is later niet meer op te vragen.
Het bewerken van de permissies of accounts van een key, en het intrekken van een key, verlopen via hetzelfde beheerproces.
De aanroep heeft een opnameverzoek aangemaakt en het beleid voor opnameverzoeken houdt dit vast ter goedkeuring. Controleer de pagina Verzoeken – het verzoek staat daar vermeld met de key als initiator, in afwachting van de benodigde goedkeuringen van Members. Dit is het bestuursmodel zoals bedoeld: automatisering stelt voor, mensen keuren goed.
Als het verzoek is goedgekeurd maar de tegoeden toch niet zijn bewogen, controleer dan of het tegoed op het bronaccount op het moment van uitvoering toereikend was – een openstaand verzoek reserveert geen tegoeden, waardoor activiteit tijdens de beoordeling een goedgekeurd verzoek kan laten mislukken. Dien het verzoek opnieuw in zodra het tegoed weer beschikbaar is.
Het account met de fout staat niet in de accountkoppeling van de key. Een key werkt alleen op de geselecteerde accounts. Bewerk de key om het account toe te voegen – houd er rekening mee dat de volledige permissieset van de key ook daar van toepassing is, omdat keys geen per-account variatie kennen. Als dat te ruim is, maak dan een tweede key aan die beperkt is tot het nieuwe account.
Een enkele Key kan rechten niet per account variëren. Maak twee Keys aan: een trade-Key gekoppeld aan account A en een alleen-lezen-Key gekoppeld aan account B. Smallere Keys zijn ook makkelijker te controleren en veiliger in te trekken.
De Manage API Keys-workflow vereist waarschijnlijk goedkeuring en het verzoek is nog in behandeling. De Key wordt pas uitgegeven en het secret getoond nadat alle vereiste goedkeuringen zijn verkregen. Controleer de status van het verzoek op de pagina Verzoeken.
Nee. Goedkeuring vereist altijd een menselijk lid. Dit is een systeemregel, geen configureerbaar beleid. Juist dit maakt meerdere-partijen-goedkeuring zinvol wanneer automatisering fondsbewegingen initieert.