Blueshift API Documentation ============================ What is Blueshift? ------------------ Blueshift is a flexible, event-driven, platform agnostic, trading and backtesting framework for developing systematic investment strategies in Python in a fast and reliable way. This makes developing complex (and simple) strategies easy, and moving a strategy from back-testing to live trading seamless. .. note:: Blueshift supports Python 3.6 and newer only. We do not have any planned release for earlier versions of Python. What it is NOT -------------- Blueshift is NOT meant for any kind of high-frequency trading (HFT). Also, Blueshift is a technical platform and engine for trading and backtesting. It in no way recommends or guarantees the performance of a particular way of trading or investing. How Blueshift Works ------------------- The Blueshift engine, at its core, consists of an event loop designed to run trading algorithms and a set of API functions to support functionalities required for a trading strategy (e.g. fetching tradable instrument details, placing orders or fetching market data etc.). A Blueshift strategy code does not run directly with the Python interpreter as a regular script would. Instead, the user strategy usually defines a set of event handling functions (or class methods) that determines how the strategy should respond if any event occurs during its run. The user strategy is read and parsed by the Blueshift engine and is run within its context, in the event loop. The core engine takes care of connecting to the broker and data source(s), running the program and keeping track of the state of the strategy (e.g. trades, orders statuses, profit and loss etc.) automatically. This allows us to focus on the trading logic of the strategy and leave the rest to Blueshift. .. _CEP: https://en.wikipedia.org/wiki/Complex_event_processing Blueshift core engine, together with user defined strategy, forms a ``Complex Event Processing`` system (CEP_). The Blueshift engine (`engine`), once launched (in either backtesting or live trading mode), does its own initialization and enters the event processing loop. In this event loop, it continuously looks for incoming events (e.g. new market data arrival or an order fill event etc.), updates its own state and calls the appropriate handler(s) defined by the user strategy at each loop iteration. The strategy codes (`strategy`, a Python script or module) written by users define a set of :ref:`callback functions
` that are called by the Blueshift engine when the specific event occurs. In addition, users can also use the :ref:`scheduling functions` for finer control. User defined `strategy` has no direct access to the event loop or its internal variables. Instead, all interactions with the algo are achieved through a set of ``API functions`` (detailed below) and by exposing two special variables -:ref:`context` and :ref:`data`. All data queries are directed through this ``data`` object. All algo state related queries (e.g. the cash in the account, current positions etc.) are directed through the ``context`` object. This simple event loop architecture allows blueshift to run any strategies that can be coded, while keeping the interface between the backtesting and live trading consistent. Blueshift APIs Overview ------------------------ Blueshift APIs can be divided into below broad categories. - Callback functions The callback functions are the entry points to the algo event loop. These are based on the lifetime events of the strategy. See :ref:`callback APIs
` for more on these. All of these callback functions accept the ``context`` variable as the first argument and the ``data`` variable as the second argument (with the exception of `initialize` and `analyze`). - Scheduling functions Scheduling functions allow finer control of event handling by precisely defining repetitive or one-time event handlers. See :ref:`schedule APIs` for more on these. These event handlers also accept two variables - ``context`` and ``data``. - Asset and Data fetching APIs Use the ``current`` and ``history`` method of the :ref:`data` object to fetch current and historical data. Use the ``symbol`` function (see :ref:`assets `) to fetch supported assets. - Trading APIs Use the base ``order`` function, or its derivatives (like ``order_target`` and ``order_target_percent``) for placing orders. Use the ``cancel_order`` to cancel an open order. Use ``get_open_orders`` to fetch current open orders. For more details, see the :ref:`trading APIs`. - Pipeline APIs Use pipelines for dynamically selecting and filtering the very large asset universe. See :ref:`pipeline APIs` for more details. - Risk management and other APIs A host of risk management APIs to put constraints on the running algo - see :ref:`risk management APIs` for details. Fine tune backtest runs using :ref:`backtest model selection APIs`. Refer to :ref:`miscellaneous APIs` for various useful functions like ``get_datetime`` and ``record``. - Context and Data Objects Attributes Use the :ref:`context object methods` for querying the state of the running algo (e.g. querying :ref:`current portfolio and account` states). Use the :ref:`Data Object` methods for fetching current or historical data. .. danger:: Backtesting and especially automated trading is far from fire-and-forget. Many things can go wrong (although we try our best to catch and highlight such cases by design). Also there are things beyond control of Blueshift that can go wrong. Like the strategy code going rogue or the datafeed being corrupt or the connectivity unstable. Be careful and remember to take appropriate precautions.