API-nycklar

Senast uppdaterad: 20 augusti 2026

API-nycklar ger automatiserade system, handelsbottar, driftskript, rapporteringspipelines och FIX-handelssessioner programmatisk åtkomst till din organisations konton. Den här artikeln beskriver behörighetsmodellen för API-nycklar, hur nycklar kopplas till konton, hur organisationsstyrning tillämpas på nyckelinitierade åtgärder och hur nyckeladministration i sig styrs.

API-nycklar är inte medlemmar med identifieringsinformation. De har sin egen, enklare behörighetsmodell:

Medlem

API-nyckel

Autentisering

Individuell inloggning med 2FA

API-nyckelns identifieringsinformation

Åtkomst till gränssnittet

Ja

Nej, endast API

Behörighetsmodell

Arbetsflödesprofil + kontoroller

API-nyckelbehörigheter tillämpas på valda konton

Variation per konto

Ja, roller kan ge olika behörigheter på olika konton

Nej, nyckelns behörigheter tillämpas enhetligt på alla valda konton

Kan initiera uttags- och överföringsförfrågningar

Ja, när det är tillåtet

Ja, när det är tillåtet

Kan godkänna förfrågningar

Ja, utom sina egna

Aldrig

Administrativa arbetsflöden

Ja, enligt sin arbetsflödesprofil

Aldrig

De två modellerna är avsiktligt separata. Medlemmar tilldelas roller, profiler och kontogranularitet eftersom människor har varierande ansvarsområden. Nycklar följer en platt modell med behörigheter och konton, eftersom automatisering bör vara avgränsad, enhetlig och lätt att granska.

En API-nyckel kombinerar två val: vad den får göra (behörigheter) och var (konton).

Behörigheter

Grupp

Behörighet

Vad den tillåter

Medel

Fråga efter medel

Visa saldon och finansieringsstatus

Sätt in

Generera insättningsadresser och visa insättningshistorik

Ta ut

Initiera uttagsförfrågningar (se "Styrning och API-nycklar")

Avkastning

Allokera och avallokera Earn-produkter

Ordrar

Hämta öppna order

Visa öppna order och aktiva affärer

Hämta stängda order

Visa historiska order och genomförda affärer

Skapa och ändra ordrar

Lägg och redigera order

Avbryt och stäng order

Avbryt öppna order och stäng positioner

Adresser

Lägg till uttagsadress

Starta förfrågningar om att lägga till vitlistade adresser

Uppdatera din uttagsadress

Starta förfrågningar om att ändra vitlistade adresser

Data

Fråga i huvudbok

Visa transaktions- och huvudbokshistorik

Exportera data

Exportera kontodata för rapportering och avstämning

Kontomappning

Varje nyckel mappas till ett eller flera konton, som väljs när nyckeln skapas och kan ändras senare. Nyckelns behörigheter gäller enhetligt för alla valda konton:

  • En nyckel med Query funds och Create and modify orders på två valda konton kan läsa saldon och utföra handel på båda – och inget annat.
  • Det finns ingen kontospecifik variation inom en nyckel. Om din automatisering behöver handla på ett konto men enbart läsa ett annat använder du två nycklar. Det gör varje nyckels räckvidd tydlig.

Välj ett specifikt konto vid behov

Privata API-förfrågningar använder organisationens primära konto när account_id utelämnas:

bash

Bash

POST /0/private/AddOrder

För att rikta anrop mot ett specifikt konto skickar du account_id som frågeparameter i URL:en:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Skicka det i URL:en, inte i anropskroppen. Ett explicit account_id har företräde framför standardvalet med primärkontot. Det utökar inte nyckelns kontomappning eller behörigheter. Om nyckeln inte kan arbeta mot det valda kontot avvisas förfrågan.

FIX-anslutning

Nycklar med orderbehörigheter stöder FIX-anslutning för spothandel, vid sidan av REST- och WebSocket-API:erna. En FIX-session har samma behörigheter och kontomappning som den bakomliggande nyckeln: den handlar bara på nyckelns valda konton, inom nyckelns behörigheter. Företag som kör FIX-orderflöden dedikerar vanligtvis en nyckel per session, begränsad till de konton som det aktuella handelsteamet hanterar.

Obs:

WebSocket-handel på andra konton än huvudkontot är ännu inte tillgänglig för API-nycklar – för närvarande är det en funktion enbart för ägare. Automatiserade orderflöden på ytterligare konton ska använda REST eller FIX. Se Tillgänglighet och begränsningar.

Säkerhetsinställningar

Inställning

Beskrivning

Nyckelns utgångsdatum

Valfritt datum efter vilket nyckeln slutar fungera

Start-/slutdatum för frågor

Begränsa datafrågor till ett datumintervall

WebSocket-anslutningar

Aktivera eller inaktivera realtidsströmning

Anpassat nonce-fönster

Justering av replay-skydd för högfrekvent användning

IP-begränsningar

Begränsa nyckelanvändning till specifika IP-adresser eller CIDR-intervall

Tips:

Ge varje nyckel minsta möjliga behörigheter, så få konton som möjligt och striktaste IP-begränsningar för att den ska kunna utföra sin uppgift. Använd separata nycklar per system – en för Handelsboten, en för rapportering – så att du kan återkalla enskilda nycklar utan att påverka resten.

Organisationens styrning gäller både vad nycklarna gör och hur de hanteras.

Vad nycklarna gör

Tvåkategoriregeln för medlemmar gäller på samma sätt för nycklar:

  • Direkta åtgärder utförs omedelbart. Handel, Earn, saldofrågor, huvudboksfrågor och dataexporter slutförs direkt, inom nyckelns behörigheter och konton.
  • Styrda åtgärder skapar förfrågningar. Ett uttag eller en adressändring som initieras av en nyckel hamnar i samma pipeline som en som initieras av en medlem: arbetsflödets policy avgör om det slutförs omedelbart eller väntar i godkännandekön för manuell granskning.

En nyckel kan bara initiera styrda förfrågningar. Nycklar kan aldrig godkänna – ansvarsfördelning kräver en mänsklig medlem för varje godkännande, och ett skript kan inte ersätta det omdömet. När policyn för uttagsförfrågningar kräver två godkännanden väntar ett nyckelinitierat uttag på två medlemmar, precis som ett medlemsinitierat uttag skulle göra.

Ett lyckat anrop är inte ett genomfört uttag

Bygg din automatisering med den asynkrona hanteringen i åtanke. WithdrawFunds returnerar approval_request_id tillsammans med refid:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • refid bekräftar att förfrågan finns, inte att medel har överförts. Beloppet spärras på källkontot när förfrågan skickas in och avräknas först när den godkänts. Se Medel spärras när du skickar in.
  • approval_request_id är referensen för det godkännande som uttaget inväntar. Spara det kopplat till din egen uttagspost.
  • Uttag som inväntar godkännande visas inte i WithdrawStatus. En förfrågan som avslås eller löper ut skapar ingen uttagspost alls, så frånvaro från WithdrawStatus innebär aldrig att ett uttag inte skickades in.

Automation som behandlar ett refid som bevis på slutförande rapporterar uttag som avräknade medan de väntar i godkännandekön, och avstämning som drar slutsatsen "inte i WithdrawStatus, alltså aldrig inskickat" ger fel svar för både väntande och avslagna förfrågningar.

Nycklar har heller ingen väg in i de administrativa arbetsflödena. Hantering av teamåtkomst, API-nycklar, konton, adresser (utöver att starta adressförfrågningar) och policyer är förbehållet medlemmar.

Hur nycklar hanteras

Att skapa, redigera och återkalla API-nycklar är en styrd åtgärd inom det dedikerade arbetsflödet Manage API Keys, skilt från Manage Team & Access. Separationen har två viktiga konsekvenser:

  • Olika administratörer. Du kan låta en driftsingenjör hantera nycklar utan möjlighet att ändra medlemmars åtkomst, och omvänt.
  • Olika policyer. Nyckelhantering kan ha egna godkännandekrav. Många organisationer kräver oberoende godkännande för att skapa eller ändra en nyckel – en ny inloggningsuppgift är en ny väg in i dina konton – men håller återkallning snabb.
  1. Gå till API-nycklar och välj Skapa nyckel.
  2. Namnge nyckeln efter dess syfte – vilket system den betjänar och vad den gör – så att funktionen är tydlig vid granskningar och säkerhetshändelser.
  3. Välj nyckelns behörigheter.
  4. Välj de konton som nyckeln ska användas på. Behörigheterna gäller enhetligt för samtliga valda konton.
  5. Konfigurera säkerhetsinställningar: utgångsdatum, IP-begränsningar, noncefönster.
  6. Granska och bekräfta. Om policyn för hantering av API-nycklar kräver godkännande väntar förfrågan tills de nödvändiga godkännandena har lämnats innan nyckeln utfärdas.
Varning:

Nyckelns hemliga värde visas bara en gång, när den skapas. Spara det på en säker plats innan du lämnar sidan – det kan inte hämtas senare.

Redigering av en nyckels behörigheter eller konton, samt återkallelse av en nyckel, följer samma styrda process.

Felsökning

Anropet skapade en uttagsförfrågan som nu väntar på godkännande enligt policyn för uttagsförfrågningar. Kontrollera sidan Förfrågningar – förfrågan visas där med nyckeln som avsändare och väntar på de nödvändiga godkännandena från medlemmar. Det här är styrningsmodellen som fungerar som avsett: automatisering föreslår, människor godkänner.

Beloppet är låst på källkontot medan förfrågan väntar och är därmed redan reserverat för uttaget. Spåra förfrågan med hjälp av det approval_request_id som returnerades med anropet.

Kontot finns inte i nyckelns kontomappning. En nyckel verkar bara på de konton den är kopplad till. Redigera nyckeln och lägg till kontot – tänk på att nyckelns alla behörigheter gäller även där, eftersom nycklar inte stödjer variation per konto. Om det är för brett kan du skapa en andra nyckel begränsad till det nya kontot.

En nyckel kan inte ha olika behörigheter per konto. Skapa två nycklar: en handelsnyckel kopplad till konto A och en skrivskyddad nyckel kopplad till konto B. Nycklar med smalare scope är också lättare att granska och säkrare att återkalla.

Arbetsflödet Hantera API-nycklar kräver troligtvis godkännande, och förfrågan väntar fortfarande. Nyckeln utfärdas, och dess hemlighet visas, först när alla nödvändiga godkännanden har samlats in. Kontrollera förfrågans status på sidan Förfrågningar.

Nej. Godkännande kräver alltid en mänsklig medlem. Det här är en systemregel, inte en konfigurerbar policy – den är det som ger flerparters-godkännande sin betydelse när automatisering initierar fondöverföringar.

Relaterade artiklar