Session management

def on_login_accepted(self, event_id: int) -> None:

def on_resend_complete(self, event_begin_id: int, event_end_id: int) -> None: 

def on_login_failed(self, reason: str) -> None:

def on_connection_failed(self, reason: str) -> None:

def on_connection_busy(self) -> None:

def on_connection_available(self) -> None:

Upon initiating the connection, the API logs in to the specified trading account on the Lime trading platform using account, username and password. Trading on the account may commence after the on_login_accepted callback is received. If the connection cannot be established or a trading account login failure occurs, the API will return an on_connection_failed or an on_login_failed callback, respectively. The callbacks are returned asynchronously. Intraday connection status failures are communicated to the client application via the same on_connection_failed callback. In case of a connection failure, the API instance is deactivated. A new instance of the API must be initiated to continue trading.

An API instance is associated with a dedicated messaging session. A single session is maintained for each account during a trading day. Every callback contains an event_id that uniquely identifies it throughout the day. Event id values start from 1 and increase monotonically throughout the day. Note that gaps in event sequence are expected since some session-level messages (e.g. heatbeats) that consume event ids are not propagated to the client application. The client application may use event_id to continue the trading session where it left off before the interruption by specifying the event_id argument in the API constructor to be the next value after the highest event id received on the session so far. As an example, a value of 1 will reult in replay of the session from the start. After the replay is complete, an on_resend_complete event is sent. An event id value of 0 is a special value that continues the session where it left off without replay.

If the order submission rate exceeds the Lime trading platform throughput for too long, buffers will fill up. At that point, the API starts rejecting calls instead of queuing them indefinitely and introducing unbounded delay. If a trading call cannot be delivered to the Lime trading platform, it is rejected synchronously with an appropriate status; optionally, an on_connection_busy callback is also placed in the callback thread. It is expected that the client application will reduce the rate of order submission once it detects congestion. The API will periodically poll the connection in congested state. When the condition clears and the connection can accept messages again, an on_connection_available callback is placed.