Reliable execution is quiet work. A trading bot that connects to the Kraken API has to live inside the exchange's rate limits and survive the occasional dropped connection without losing track of what it was doing. Done well, none of this is visible. Done badly, it shows up as missed orders, duplicate orders, or a bot that thinks a position is open when it is not.
What rate limits are
An exchange API caps how many requests it will accept in a window of time. This protects the venue from overload and applies to everyone. A disciplined bot tracks how close it is to those limits and paces its requests so it never gets throttled at the worst possible moment — for instance, while trying to manage an open position.
Backing off instead of hammering
When the API signals that a request was refused or delayed, the right response is to back off and retry with increasing patience, not to hammer the endpoint harder. Hammering makes throttling worse and can turn a brief hiccup into a sustained outage from the bot's point of view.
Reconnecting without losing state
Connections drop. The question is what happens next. A reliable bot reconnects cleanly and then reconciles: it asks the exchange what actually happened to any in-flight orders rather than assuming. That reconciliation is what prevents the two worst outcomes — placing a duplicate order, or believing an order filled when it did not.
Every gap is logged
A throttle, a disconnect, and a reconnection are all recorded in the audit trail. That matters because it lets you reconstruct exactly what the bot saw and did during a rough patch, instead of guessing. Reliability you cannot inspect is just hope.
To read those records, see how to read the execution audit trail. For the orders being placed across the connection, see order types on Kraken. None of this is a Kraken product; it describes how a disciplined bot behaves against the API. Reliable execution never implies a profitable trade.