Hoe los je API-sleutelverbindingsfouten op voor cryptohandelbots?

Wanneer een cryptohandelsbot geen verbinding kan maken met Binance of OKX, kan de melding zo algemeen zijn als 'authenticatie mislukt' of 'ongeldige API-sleutel'. Die melding betekent niet per se dat de sleutel zelf onjuist is. De fout kan te maken hebben met machtigingen, een IP-whitelist, een niet-overeenkomend product-eindpunt, een onjuist geformuleerde handtekening, een klok die niet synchroon loopt of een limiet voor het aantal verzoeken.

Deze handleiding gebruikt één hypothetisch voorbeeld als leidraad. Het is slechts een illustratief voorbeeld – geen echte test, resultaat of getuigenis: Maya heeft een spottradingbot gemaakt en krijgt een verbindingsfout nadat ze de inloggegevens van een exchange-account heeft ingevoerd. Het onderstaande stappenplan voor probleemoplossing laat zien hoe ze de oorzaak kan achterhalen zonder haar geheime gegevens prijs te geven of onnodige toegang tot accounts te verlenen. Uw exchange-interface, botprovider en foutmelding kunnen afwijken.

Wat moet je doen voordat je de API-sleutel wijzigt?

Pauzeer de bot en voorkom automatische herhaalpogingen terwijl u het probleem onderzoekt. Herhaalde mislukte verzoeken kunnen het lastiger maken om een ​​probleem met de snelheidslimiet te onderscheiden van een authenticatieprobleem. Bewaar de exacte foutmelding, HTTP-status, beursnaam, producttype, eindpunt (indien de bot dit weergeeft) en het tijdstip van de fout. Plak nooit een API-geheim, wachtwoordzin, ondertekend verzoek of volledige autorisatieheader in een openbaar probleem, chat, screenshot of supportticket.

Een API-sleutel identificeert de integratie. Het API-geheim is de privéwaarde die wordt gebruikt om verzoeken te ondertekenen, en een API-wachtwoordzin is een aanvullende authenticatie die door sommige exchanges, waaronder OKX, wordt vereist. Behandel ze allemaal als vertrouwelijk. Als een geheim is gelekt, trek dan die sleutel in en maak een vervangende sleutel aan via de officiële accountinterface van de exchange voordat u verdergaat.

Tot welke foutfamilie behoort dit bericht?

Begin met classificatie in plaats van willekeurige bewerkingen. Authenticatie- en autorisatiefouten wijzen meestal op problemen met inloggegevens, machtigingen, IP-beperkingen of ondertekening. Tijdfouten wijzen op de klok van de machine of de tijdstempel van het verzoek. Netwerk- en snelheidslimietfouten vereisen een andere aanpak: controleer de bereikbaarheid, vertraag verzoeken en controleer of een eerdere opdracht mogelijk is geaccepteerd voordat u het opnieuw probeert.

Deze codes en berichten zijn gedocumenteerde referenties, geen garantie dat elke bot ze ongewijzigd zal weergeven. Een bot van derden kan het antwoord op de uitwisseling vertalen, inkorten of aanpassen.

Hoe controleer je de status en machtigingen van een API-sleutel?

Open de API-beheerpagina van de exchange rechtstreeks via de officiële website of app. Controleer of de sleutel actief is, bij het beoogde account of subaccount hoort en bedoeld is voor het product dat de bot gaat gebruiken. Een sleutel die voor één omgeving of account is aangemaakt, werkt mogelijk niet voor een andere.

Pas het principe van minimale bevoegdheden toe. Een bot die alleen saldi leest, heeft leesrechten nodig. Een bot die spotorders plaatst en annuleert, heeft handelsrechten van de beurs nodig. Opnames zijn een aparte functionaliteit en moeten uitgeschakeld blijven, tenzij er een specifieke, duidelijke reden is om ze in te schakelen. Een succesvolle verbinding bewijst niet dat de bot orders kan plaatsen, en een toestemmingsfout tijdens een ordertest betekent niet automatisch dat de inloggegevens ongeldig zijn.

In het hypothetische voorbeeld controleert Maya eerst of haar bot is geconfigureerd voor spottrading, terwijl de sleutel alleen leesrechten heeft. Ze noteert de vereiste machtiging uit de documentatie van de bot, schakelt alleen die machtiging in indien van toepassing, slaat de wijziging op en wacht tot de beurs deze heeft toegepast. Ze schakelt opnames niet in, puur om de verbindingstest te laten slagen.

Zou een IP-whitelist de bot kunnen blokkeren?

Een IP-whitelist, ook wel IP-allowlist genoemd, beperkt het gebruik van een API tot goedgekeurde bronadressen. Dit verbetert de beveiliging, maar kan een perfect geldige sleutel blokkeren wanneer de bot draait vanaf een cloudserver, container, thuisverbinding of provider waarvan het uitgaande IP-adres is gewijzigd. Vraag de botprovider naar het exacte uitgaande IP-adres of de exacte uitgaande IP-adressen. Ga niet af op het openbare IP-adres van uw laptop als de bot daadwerkelijk ergens anders draait.

Vergelijk het adres dat de provider weergeeft met de whitelist van de exchange. Controleer of het om IPv4 of IPv6 gaat, of er spaties of verouderde vermeldingen in staan ​​en of de sleutel aan het juiste account is gekoppeld. Als de provider een roterend adresbereik gebruikt, vraag dan of er een stabiel uitgaand IP-adres wordt aangeboden. Schakel de whitelist niet permanent uit als snelle oplossing; als u deze tijdelijk verwijdert voor een gecontroleerde diagnose, herstel deze dan onmiddellijk en roteer de sleutel als de wijziging een gevoelige integratie aan het licht heeft gebracht.

Zijn de sleutel, het geheim en de wachtzin afkomstig van dezelfde integratie?

Kopieer de inloggegevens opnieuw, zonder spaties, aanhalingstekens, regeleinden of verborgen tekens toe te voegen. Controleer of de API-sleutel en het geheim als één paar zijn gegenereerd. Controleer op OKX ook de exacte wachtzin die is ingevoerd bij het aanmaken van de sleutel. De wachtzin is niet hetzelfde als het inlogwachtwoord van het account, en de beurs geeft aan dat een verloren wachtzin niet kan worden hersteld; een nieuwe sleutelset is vereist.

Controleer de geselecteerde beurs in de bot. Een Binance-sleutel kan een OKX-verzoek niet authenticeren en een sleutel van een hoofdaccount vertegenwoordigt mogelijk niet het subaccount waarmee u wilde handelen. Als u niet zeker weet welke waarde in welk veld is geplakt, trek dan de betreffende sleutel in en maak een nieuw valutapaar aan in plaats van herhaaldelijk een onbekende sleutel te testen.

Hoe ontstaan ​​fouten in handtekeningen en tijdstempels?

Privé API-verzoeken worden niet geverifieerd door het geheim in platte tekst te verzenden. De client bouwt een nauwkeurige ondertekeningspayload op en genereert een handtekening. Een enkele afwijking – zoals een gewijzigde parametervolgorde, een verschil in URL-codering, een verkeerde HTTP-methode, een verkeerd geheim of een gewijzigde verzoekbody – kan de handtekening ongeldig maken.

Voor Binance Spot REST-verzoeken beschrijft de officiële documentatie het gebruik van HMAC-SHA-256-ondertekening voor HMAC-sleutels en vereist een tijdstempel op ondertekende verzoeken. De documentatie legt ook recvWindowhet toegestane tijdsvenster uit. De huidige referentie toont een voorbeeldwaarde van vijf seconden, maar de instellingen van een bot en de limieten van de beurs kunnen variëren; gebruik de waarde die door het eindpunt wordt ondersteund en voorkom dat een klokprobleem wordt gemaskeerd met een onnodig groot tijdsvenster.

OKX privé REST-verzoeken gebruiken headers zoals OK-ACCESS-KEY, OK-ACCESS-SIGN, OK-ACCESS-TIMESTAMP, en OK-ACCESS-PASSPHRASE. OKX beschrijft een pre-hash gemaakt van timestamp, HTTP-methode, verzoekpad en body, gevolgd door HMAC-SHA-256 en Base64-codering. Het specificeert ook ISO 8601 UTC-tijd met millisecondenprecisie en adviseert synchronisatie met het openbare tijd-eindpunt. Zorg ervoor dat de klok, HTTP-methode, pad, queryparameters en body van de bot overeenkomen met wat de bot ondertekent.

In Maya's hypothetische scenario registreert de bot een ongeldige handtekening in plaats van een geweigerde toestemming. Ze vergelijkt de gedocumenteerde ondertekeningsmethode van de botaanbieder met de geselecteerde exchange, controleert of het geheim niet is afgekapt, synchroniseert de serverklok met UTC en test een onschadelijk, geauthenticeerd lees-eindpunt. Als de aanbieder de ondertekening intern beheert, levert ze alleen de vervangende inloggegevens via het beveiligde geheime veld en vraagt ​​ze de aanbieder om de geredigeerde logs te inspecteren.

Gebruikt de bot de juiste omgeving en het juiste product-eindpunt?

Scheid de "productie"- of mainnetomgeving van de "testnet"- of demoomgeving. Een sleutel die voor de ene omgeving is aangemaakt, werkt mogelijk niet voor de andere. Maak ook onderscheid tussen spot-, margin-, futures- en optie-endpoints. Hetzelfde valutapaar kan verschillende symbolen, machtigingen, accountmodi en orderregels hebben voor verschillende producten.

Lees de handleiding voor de integratie met de exchange van de bot en vergelijk de basis-URL, productselector, accounttype, symboolformaat en WebSocket- of REST-modus met de actuele documentatie van de exchange. Als de bot aparte integraties biedt voor Binance Spot en Futures, kies dan de integratie die overeenkomt met de sleutel en de strategie. Schakel nooit over naar een live endpoint alleen omdat een testnet-authenticatie mislukt is.

Zou de verbinding mogelijk verbroken worden door snelheidslimieten of netwerkproblemen?

Zodra de inloggegevens correct zijn, controleer dan het aanvraagpatroon. Een bot die te vaak saldi, openstaande orders en marktgegevens opvraagt, kan de limieten bereiken, zelfs als elke handtekening geldig is. Binance documenteert -1003 TOO_MANY_REQUESTSen adviseert het gebruik van WebSocket-streams voor live updates waar nodig. OKX documenteert 50011wanneer de limiet voor het aantal aanvragen is bereikt en merkt op dat limieten per eindpunt verschillen en gebaseerd kunnen zijn op IP-adres of gebruikers-ID.

Verminder dubbele polling, voeg exponentiële backoff toe, beperk het aantal herhaalpogingen en voorkom dat er meerdere bot-instanties met dezelfde integratie worden gestart. Een time-out is geen bewijs dat een order is mislukt: controleer de orderstatus voordat u een dubbele order verzendt. Controleer ook DNS, firewallregels, uitgaande HTTPS-toegang, proxy-instellingen, TLS-interceptie en of het exchange-eindpunt beschikbaar is in uw regio of voor uw account.

Wat is de veiligste manier om na een correctie opnieuw te testen?

1. Sla de exacte wijziging die je hebt aangebracht op, zoals het corrigeren van de IP-whitelist of het selecteren van Spot.
2. Gebruik eerst een alleen-lezen, geauthenticeerde aanvraag, bijvoorbeeld om rekeninggegevens of saldi op te vragen.
3. Bevestig dat de bot het beoogde account en product rapporteert, zonder geheime gegevens weer te geven.
4. Als een ordertest nodig is, gebruik dan de kleinst mogelijke omvang en een gecontroleerde markt, maar alleen nadat u de gevolgen, kosten en accountmodus begrijpt.
5. Controleer de logbestanden op geanonimiseerde statuscodes, tijdstempels, eindpuntnamen en het aantal herhaalpogingen.
6. Stop en roteer de sleutel als de fout aanhoudt nadat de basisgegevens zijn geverifieerd, of als de sleutel mogelijk naar een onbetrouwbare service is gekopieerd.

Welke fouten moet je vermijden?

• Publiceer of verstuur het API-geheim niet via e-mail, zelfs niet wanneer u om hulp bij het debuggen vraagt.
• Schakel opnames niet in als een snelle oplossing bij een mislukte authenticatie.
• Voeg geen breed of onbekend IP-bereik toe aan een whitelist, alleen maar om een ​​foutmelding te voorkomen.
• Probeer een onzekere bestelling na een time-out niet blindelings opnieuw uit te voeren; controleer eerst de status.
• Ga er niet van uit dat een sleutel geldig is voor elk exchange-product, subaccount, regio of omgeving.
• Verhoog de pollingfrequentie niet tijdens het onderzoeken van een storing.
• Vertrouw niet op een oude schermafbeelding van een pagina met Exchange-instellingen in plaats van op de actuele officiële documentatie.

Officiële referenties en beperkingen van deze handleiding

Raadpleeg voor de betekenis van de codes en details over ondertekening de actuele referentie voor foutcodes van de Binance Spot API en de documentatie van de Binance Spot REST API . Raadpleeg voor OKX-authenticatie, tijdssynchronisatie, machtigingen, foutcodes en snelheidslimieten de OKX API-handleiding . Deze documenten van de leveranciers kunnen wijzigen, dus controleer ze opnieuw wanneer uw botprovider een integratie-update uitbrengt.

Dit artikel is opgesteld aan de hand van de beschikbare officiële bronnen op 16 september 2026. Het beschrijft een diagnosemethode en biedt geen garantie dat een specifieke bot, exchange-account, jurisdictie of API-versie zal werken. Als de exchange een beveiligings-, compliance-, accountblokkerings- of productbeschikbaarheidsmelding weergeeft, volg dan de officiële ondersteuningsprocedure van de exchange en probeer de beperking niet te omzeilen.