API-nøkler

API-nøkler er ikke medlemmer med påloggingsopplysninger. De har sin egen, enklere tillatelsesmodell:

De to modellene er bevisst atskilt. Medlemmer får roller, profiler og detaljert tilgangsstyring per konto fordi mennesker tar på seg stadig nye ansvarsområder. Nøkler bruker en flat modell med faste tillatelser og kontoer, fordi automatisering bør være avgrenset, ensartet og lett å revidere.

En API-nøkkel kombinerer to valg: hva den kan gjøre (tillatelsene) og hvor (kontoene).

Tillatelser

Kontotilordning

Hver nøkkel tilordnes én eller flere kontoer, valgt når nøkkelen opprettes og redigerbar senere. Nøkkelens tillatelser gjelder likt for alle valgte kontoer:

• En nøkkel med Query funds og Create and modify orders på to valgte kontoer kan lese saldoer og handle på begge – og ingenting annet.
• Det er ingen per-konto-variasjon innenfor én nøkkel. Hvis automatiseringen din trenger å handle på én konto, men bare lese en annen, bruk to nøkler. Dette gjør nedslagsfeltet til hver nøkkel tydelig.

Velg en bestemt konto ved behov

Private API-forespørsler bruker organisasjonens primærkonto når account_id utelates:

For å utføre operasjoner på en bestemt konto, send account_id som en query-parameter i URL-en:

Send den i URL-en, ikke i forespørselsteksten. En eksplisitt account_id har forrang over primærkonto-fallback. Den utvider ikke nøkkelens kontotilordning eller tillatelser. Hvis nøkkelen ikke kan operere på den valgte kontoen, avvises forespørselen.

FIX-tilkobling

Nøkler med ordretillatelser støtter FIX-tilkobling for spot-handel ved siden av REST- og WebSocket-API-ene. En FIX-sesjon har de samme tillatelsene og kontotilordningen som nøkkelen bak den: den handler kun på nøkkelens valgte kontoer, innenfor nøkkelens tillatelser. Selskaper som kjører FIX-ordreflyt, dedikerer vanligvis én nøkkel per sesjon, avgrenset til kontoene det aktuelle handelsteamet opererer på.

Sikkerhetsinnstillinger

Selskapsstyring gjelder både for hva nøkler gjør og hvordan de administreres.

Hva nøkler gjør

Tokategoriregelene for Medlemmer gjelder på samme måte for nøkler:

• Direkte operasjoner utføres umiddelbart. Handel, Tjen, saldospørringer, hovedbokspørringer og dataeksporter fullføres umiddelbart, innenfor nøkkelens tillatelser og kontoer.
• Styrte operasjoner oppretter forespørsler. Et uttak eller en adresseendring som startes av en nøkkel, går inn i samme flyt som én startet av et Medlem: arbeidsflytens policy avgjør om den fullføres umiddelbart eller venter i godkjenningskøen for manuell gjennomgang.

En nøkkel kan bare starte styrte forespørsler. Nøkler har aldri godkjenningstilgang – ansvarsfordeling krever et menneskelig Medlem for hver godkjenning, og et skript kan ikke erstatte den vurderingen. Når policyen for uttaksforespørsler krever to godkjenninger, venter et nøkkelinitiert uttak på to Medlemmer – nøyaktig slik et medlemsinitiert uttak ville gjort.

Et vellykket kall er ikke et fullført uttak

Bygg automatiseringen din rundt denne asynkroniteten. WithdrawFunds returnerer approval_request_id sammen med refid:

• refid bekrefter at forespørselen finnes, ikke at midler er overført. Beløpet låses på kildekontoen ved innsending og gjøres opp først når forespørselen er godkjent. Se Midler låses når du sender inn.
• approval_request_id er håndtaket for godkjenningen uttaket venter på. Lagre den sammen med din egen registrering av uttaket.
• Uttak som venter på godkjenning vises ikke i WithdrawStatus. En forespørsel som avvises eller utløper, oppretter ingen uttaksregistrering, så fravær fra WithdrawStatus betyr aldri at et uttak ikke ble sendt inn.

Automatisering som behandler en refid som bevis på fullføring, vil rapportere uttak som gjort opp mens de ligger i godkjenningskøen – og avstemming som konkluderer med «ikke i WithdrawStatus, derfor aldri sendt inn» vil være feil for både ventende og avviste forespørsler.

Nøkler har heller ingen tilgang til de administrative arbeidsflytene. Administrasjon av teamtilgang, API-nøkler, kontoer, adresser (utover å starte adresseforespørsler) og retningslinjer er forbeholdt Medlemmer.

Hvordan nøkler administreres

Oppretting, redigering og tilbakekalling av API-nøkler er en styrt operasjon under den dedikerte Manage API Keys-arbeidsflyten, atskilt fra Manage Team & Access. Skillet har betydning på to måter:

• Ulike administratorer. Du kan la en driftsansvarlig administrere nøkler uten mulighet til å endre Medlemmers tilgang, og omvendt.
• Ulike retningslinjer. Nøkkeladministrasjon kan ha egne godkjenningskrav. Mange organisasjoner krever uavhengig godkjenning for å opprette eller endre en nøkkel – en ny legitimasjon er en ny inngang til kontoene dine – men holder tilbakekalling rask.

1. Gå til API-nøkler og velg Opprett nøkkel.
2. Gi nøkkelen et navn som beskriver formålet – systemet den betjener og hva den gjør – slik at funksjonen er tydelig ved gjennomganger og sikkerhetshendelser.
3. Velg nøkkelens tillatelser.
4. Velg kontoene nøkkelen skal gjelde for. Tillatelsene gjelder likt for alle de valgte kontoene.
5. Konfigurer sikkerhetsinnstillinger: utløpsdato, IP-begrensninger, nonce-vindu.
6. Se gjennom og bekreft. Hvis policyen for Administrer API-nøkler krever godkjenning, venter forespørselen på de nødvendige godkjenningene før nøkkelen utstedes.

Redigering av tillatelser eller kontoer, og tilbakekalling av en nøkkel, følger den samme styrte prosessen.

Kallet opprettet en uttaksforespørsel, og policyen for uttaksforespørsler holder den tilbake for godkjenning. Sjekk siden Forespørsler – forespørselen vises der med nøkkelen som initiativtaker og venter på de nødvendige medlemsgodkjenningene. Dette er styringsmodellen som fungerer som tiltenkt: automatisering foreslår, mennesker godkjenner.

Beløpet er låst på kildekontoen mens forespørselen venter, og er dermed allerede reservert for uttaket. Spor forespørselen ved hjelp av approval_request_id som returneres med kallet.

Kontoen som feiler er ikke lagt til i nøkkelens kontotilordning. En nøkkel opererer kun på de kontoene den er tilordnet. Rediger nøkkelen for å legge til kontoen – merk at nøkkelens fulle tillatelsessett gjelder der, ettersom nøkler ikke har per-konto-variasjon. Hvis det er for bredt, opprett en ny nøkkel avgrenset til den aktuelle kontoen.

En enkelt nøkkel kan ikke ha ulike tillatelser per konto. Opprett to nøkler: én handelsnøkkel tilknyttet konto A og én skrivebeskyttet nøkkel tilknyttet konto B. Smalere nøkler er også enklere å revidere og sikrere å tilbakekalle.

Arbeidsflyten for administrasjon av API-nøkler krever sannsynligvis godkjenning, og forespørselen er fortsatt til behandling. Nøkkelen utstedes og hemmeligheten vises først etter at alle nødvendige godkjenninger er innhentet. Sjekk statusen til forespørselen på Forespørsler-siden.

Nei. Godkjenning krever alltid et menneskelig medlem. Dette er en systemregel, ikke en konfigurerbar policy – den er det som gjør flepartsgodkjenning meningsfull når automatisering initierer pengebevegelser.