API-sleutels

API keys zijn geen Members met inloggegevens. Ze hebben hun eigen, eenvoudigere rechtenmodel:

De twee modellen zijn bewust gescheiden. Members krijgen rollen, profielen en accountspecifieke granulariteit, omdat mensen uiteenlopende verantwoordelijkheden opdoen. Keys krijgen een plat scope-plus-accounts-model, omdat automatisering afgebakend, uniform en in één oogopslag controleerbaar moet zijn.

Een API key combineert twee keuzes: wat hij mag doen (de rechten) en waar (de accounts).

Toestemmingen

Account-koppeling

Elke key is gekoppeld aan één of meer accounts, geselecteerd bij aanmaak en later aanpasbaar. De rechten van de key gelden voor elk geselecteerd account:

• Een key met de rechten "Tegoeden opvragen" en "Orders aanmaken en wijzigen" op twee geselecteerde accounts kan tegoeden lezen en traden op beide accounts, en verder niets.
• Binnen één key gelden de rechten uniform voor alle accounts — geen per-account variatie mogelijk. Als je automatisering op één account moet traden maar een ander alleen moet kunnen lezen, gebruik dan twee keys. Zo blijft het bereik van elke key overzichtelijk en controleerbaar.

Selecteer een specifiek account indien nodig

Privé-API-verzoeken gebruiken het primaire account van de organisatie als account_id wordt weggelaten:

Om op een specifiek account te werken, geef je account_id mee als queryparameter in de URL:

Geef het mee in de URL, niet in de request body. Een expliciete account_id heeft voorrang op het primaire account als fallback. Dit breidt de account-mapping of de rechten van de Key niet uit. Als de Key niet op het geselecteerde account kan werken, wordt het verzoek geweigerd.

FIX-connectiviteit

Keys met order-rechten ondersteunen FIX-connectiviteit voor Spot-trading, naast de REST- en WebSocket-API's. Een FIX-sessie heeft dezelfde rechten en account-mapping als de bijbehorende Key: trades worden uitsluitend uitgevoerd op de geselecteerde accounts van de Key, binnen de bijbehorende rechten. Bedrijven die FIX-orderflow gebruiken, wijzen doorgaans één Key per sessie toe, beperkt tot de accounts waarop de desk tradt.

Beveiligingsinstellingen

Het Bestuur van de Organisatie bepaalt wat keys doen en hoe keys worden beheerd.

Wat keys doen

De twee-categorieënregel voor Members geldt ook voor keys:

• Directe bewerkingen worden onmiddellijk uitgevoerd. Trades, Earn, tegoedbevragingen, grootboekbevragingen en data-exports worden direct voltooid, binnen de machtigingen en accounts van de key.
• Bestuurde bewerkingen genereren verzoeken. Een opname of adreswijziging die door een key wordt gestart, doorloopt dezelfde pijplijn als een verzoek van een Member: het workflowbeleid bepaalt of het direct wordt afgerond of in de goedkeuringswachtrij belandt voor menselijke beoordeling.

Een key kan uitsluitend bestuurde verzoeken initiëren. Keys hebben nooit de Goedkeuren-bevoegdheid: functiescheiding vereist een menselijke Member voor elke goedkeuring, en een script kan dat oordeel niet overnemen. Als het beleid voor Opnameverzoeken twee goedkeuringen vereist, wacht een key-geïnitieerde opname op twee Members – precies zoals een Member-geïnitieerde opname dat zou doen.

Een geslaagde aanroep is geen voltooide opname

Stem je automatisering af op die asynchronie. WithdrawFunds geeft approval_request_id terug samen met refid:

• refid bevestigt dat het verzoek bestaat, niet dat de tegoeden zijn verplaatst. Het bedrag wordt bij indiening vergrendeld op het bronaccount en wordt pas vereffend zodra het verzoek is goedgekeurd. Zie Tegoeden worden vergrendeld bij indiening.
• approval_request_id is de referentie voor de goedkeuring waar de opname op wacht. Sla deze op bij je eigen administratie van de opname.
• Opnames die wachten op goedkeuring verschijnen niet in WithdrawStatus. Een verzoek dat wordt afgewezen of verloopt laat geen opnamerecord achter, dus het ontbreken van een vermelding in WithdrawStatus betekent nooit dat een opname niet is ingediend.

Automatisering die een refid als bewijs van voltooiing behandelt, rapporteert opnames als vereffend terwijl ze nog in de goedkeuringswachtrij staan. Reconciliatie die concludeert „niet in WithdrawStatus, dus nooit ingediend" is onjuist voor zowel openstaande als afgewezen verzoeken.

Keys hebben ook geen toegang tot de administratieve workflows. Toegangsbeheer voor teams, API keys, accounts, adressen (buiten het starten van adresverzoeken) en beleid is voorbehouden aan Members.

Beheer van keys

Het aanmaken, bewerken en intrekken van API keys is een beheerde bewerking binnen de speciale Manage API Keys-workflow, los van Manage Team & Access. Deze scheiding is op twee manieren van belang:

• Verschillende beheerders. Je kunt een operations engineer keys laten beheren zonder dat die de toegang van Members kan wijzigen, en omgekeerd.
• Verschillend beleid. Key-beheer kan eigen goedkeuringsvereisten hebben. Veel organisaties vereisen onafhankelijke goedkeuring om een key aan te maken of te wijzigen – een nieuwe credential is een nieuwe toegangsroute tot je accounts – maar houden intrekking bewust snel.

1. Ga naar API keys en selecteer Create key.
2. Geef de key een naam die het doel beschrijft: het systeem dat hij bedient en wat hij doet, zodat de functie meteen duidelijk is bij audits en beveiligingsincidenten.
3. Selecteer de rechten van de key.
4. Selecteer de accounts waarop de key actief is. De rechten gelden voor al deze accounts zonder uitzondering.
5. Stel de beveiligingsinstellingen in: vervaldatum, IP-beperkingen, nonce-periode.
6. Controleer en bevestig. Als het beleid Manage API Keys goedkeuring vereist, wacht het verzoek op de vereiste goedkeuringen voordat de key wordt uitgegeven.

Het aanpassen van de rechten of accounts van een key, en het intrekken van een key, volgen hetzelfde goedkeuringsproces.

De aanroep heeft een opnameverzoek aangemaakt, en het beleid voor opnameverzoeken houdt dit aan voor goedkeuring. Ga naar de pagina Verzoeken – het verzoek staat daar vermeld met de key als initiator, in afwachting van de benodigde goedkeuringen van Members. Het bestuursmodel werkt hier zoals bedoeld: automatisering doet een voorstel, mensen keuren goed.

Het bedrag wordt geblokkeerd op het bronaccount zolang het verzoek in behandeling is, en is dus al gereserveerd voor de opname. Volg het verzoek via de approval_request_id die de aanroep retourneert.

Het account dat problemen geeft, is niet opgenomen in de accountkoppeling van de key. Een key werkt uitsluitend op de accounts die eraan zijn gekoppeld. Bewerk de key om het account toe te voegen, maar houd er rekening mee dat alle rechten van de key daar eveneens gelden – keys kennen geen rechten per account. Is dat te ruim, maak dan een tweede key aan die beperkt is tot het nieuwe account.

Een enkele Key kan geen verschillende rechten per account hebben. Maak twee Keys aan: een trading Key gekoppeld aan account A en een alleen-lezen Key gekoppeld aan account B. Smallere Keys zijn ook makkelijker te auditen en veiliger in te trekken.

De workflow voor het beheren van API Keys vereist waarschijnlijk goedkeuring en het verzoek is nog in behandeling. De Key wordt pas aangemaakt en het geheim getoond nadat de vereiste goedkeuringen zijn verleend. Controleer de status van het verzoek op de pagina Verzoeken.

Nee. Goedkeuring vereist altijd een menselijk Member. Dit is een systeemregel, geen configureerbaar beleid – het is precies wat meervoudige goedkeuring zinvol maakt wanneer automatisering geldoverboekingen initieert.