MLink

The SpiderRock Connect MLink API provides access to live-data objects from a SpiderRock Connect system environment. This page provides documentation for how developers can connect to MLink servers and send or receive these live-data objects.

The MLink API has the following primary features:

• HTTP/REST style API including GET and POST commands, filtering, aggregation.
• HTTP/WebSocket style API for subscribing to live-data updates in both narrow and broad contexts.
• 3 message delivery protocols: JSON, Framed JSON or Google Protocol Buffers
• Real-time, delayed, and simulated market data
• Access via API Key or TOTP/Session Key authentication*
• A rich set of data topics that cover live market data and analytics as live risk and trading live-data objects.
• Full on-line message schema support for all live-data objects.

Message Categories

In MLink, messages are organized and permissioned by MLink tokens. Access to live-data objects is granted by associating an MLink token with the API Key / UserName used to log in. The full set of available MLink tokens can be found in the Message Schemas section of this site which is generated directly from the current system codebase and is always up to date.

Some examples of MLink Tokens are:

Token	Description
EqtMktData	Stock quote and prints
OptMktData	Options quote and prints
FutMktData	Futures quote and prints
EqtMarkData	Stock open and close marks
OptMarkData	Options open, close, surface, closing greeks marks
FutMarkData	Futures open, close and settlement marks
EqtExchImbalance	Stock market auction imbalances
OptSurface	Options surfaces, at-the-money volatility and related
OptAnalytics	Options implied quotes and risk slides
OptExchAuction	Auction State trial match message
RiskCalc	Option Volatility and Price Calculator
EquityDefinition	Production definitions for equities
ClientTrading	Client Trading (Orders, Executions) messages
ClientRisk	Client Risk messages
SRConnect	Auction related messages for the ATS

Message Patterns

All MLink messages are generated from a core system object IDL and follow common patterns, including the following:

1. Live Data Objects with Primary Key:

   These messages have a well-defined primary key (unique per message type) and follow a create/replace pattern such that any new message arriving in MLink will completely replace the previous record with the same primary key, if one exists. NOTE: any REST query for this message pattern will result in the current, cached copy of all responsive records being returned to the client. An example of this pattern is msgOptionNBBOQuote.

2. Security Keys:

   Several messages contain security keys (TickerKey, ExpiryKey, and/or OptionKey)

   • TickerKey: SSSS-TS-AT where SSSS is the security symbol (eg. AAPL), TS is a ticker source (eg. NMS), and AT is a asset type (eg. EQT).
   • ExpiryKey: SSSS-TS-AT-YYYY-MM-DD where YYYY is year, MM is month, and DD is day.
   • OptionKey: SSSS-TS-AT-YYYY-MM-DD-XXXX-CP where XXXX is the strike price, and CP is either (Call, Put, or Both).

   Ticker Sources (ts) can be of the following:

   • None=0,SR=1,NMS=2,CME=3,ICE=4,CFE=5,CBOT=6,NYMEX=7,COMEX=8,RUT=9,CIDX=10,ARCA=11,NYSE=12,OTC=13,NSDQ=14,MFQS=15,MIAX=16,DJI=17,CUSIP=18,ISIN=19

   Asset Types (at) can be of the following:

   • None=0,EQT=1,IDX=2,BND=3,CUR=4,COM=5,FUT=6,SYN=7,WAR=8,FLX=9,MUT=10,SPD=11,MM=12,MF=13,COIN=14,TOKEN=15

3. Special Data Objects:

   • Spreads: #SSSShhhh where hhhh is a hexadecimal ID number. It is not possible to determine the security being traded without referring to the associated product definition.
   • FLEX: encoded as OptionKeys with the security symbol being the standard FLEX root.
   • Market Data: distributed with one of the above security keys where the symbol is the exchange trading symbol. Product definition records are available for all trading instruments that contain more complete details.
   • Synthetics: _SSSS or SSSS_ computed for the purpose of pricing options more accurately (eg. multi-hedge basket underliers or roll+model derived options on futures quotes).

4. Admin Data Objects without Primary Keys:

   Some SR MLink objects do not have natural primary keys and are used as administrative messages between MLink and a client. An example of this pattern is "MLinkLogon".

5. HTTP/REST Admin Messages:

   Messages	Description
   MLinkApiKey	Used to return a temporary ApiKey (./getapikey)
   QueryResult	Futures quote/print metrics (the last message in a response.body block) (./getmsg or ./getmsgs)
   MsgDesc	Message Description (describes an SR message) (in response to ./getmsgtypes call)
   FieldDesc	Field Description (schema) (in response to a ./getschema call)
   SummaryNumeric	Summary detail for a numeric field (in response to a ./getsummary call)
   SummaryString	Summary detail for a string field (in response to a ./getsummary call)
   PostAck	Post acknowlegement for an individual SR message post attempt (./postmsgs)

6. MLink/WebSocket Admin Messages:

   Messages	Description
   MLinkAdmin	Sent in response to a WebSocket connect attempt and also in response to an MLinkLogon message
   MLinkLogon	Used to logon (authenticate) (only required if credentials were not supplied in initial HTTP connect)
   MLinkStream	Set or update the active subscription query for this session
   MLinkStreamAck	Sent in repsponse to an MLinkStream attempt
   MLinkStreamCheckPt	Query Check Point (None=0,Begin=1,Active=2,Complete=3,Replaced=4,Terminated=5)
   MLinkSignalReady	Used to signal that the client is ready for more messages (live subscriptions w/o an active latency)
   MLinkDataAck	Sent in response to an message upload attempt
   MLinkSubscribe	Set or update an active subscription for a session by msgPKey
   MLinkSubscribeAck	Sent in reponse to an MLinkSubscribe attempt
   MLinkSubscribeCheckPt	Subscription Check Point (None=0,Begin=1,Active=2,Terminated=3)
   MLinkHeartbeat	MLink Connection heart beat; sent by default every 10 seconds

Connection Types

You can connect to the MLink API through 2 different connection types: REST or Websocket.

1. The REST API should be used for applications that need to query data from time to time, this connection type allows for more conservative message consumption which keeps costs lower.

2. The Websocket connection should be used for applications that require a live subscription to data, this connection type flows data to the screen automatically and tends to consume more messages as a result.