2.0 General

Contents:

• 2.1 Authentication
• 2.2 Data Flow

The API you expose is a plain JSON-over-HTTP service. MollyBet polls it; you do not need to call us for anything. If you also implement the optional offers WebSocket, you can push events, prices and liquidity to us instead of waiting to be polled.

2.0.1 Expected formats

These conventions apply to every endpoint and are not repeated on each page.

Subject	Rule
Prices	Decimal odds, to three places after the decimal point.
Stakes and amounts	In the currency of the account, as a [currency, amount] pair.
Dates and datetimes	UTC, in ISO 8601.
Response bodies	JSON.

Amounts are always paired with their currency rather than sent bare. See Currency amounts.

2.0.2 What is optional

The specification is deliberately forgiving about the parts that MollyBet can handle for you:

• Settlement. If you do not settle bets yourself, MollyBet can do it. You still need to report bet states through the bets endpoints.
• Multiple users. A single account with one shared API key is sufficient. How you organise users beyond that is up to you.
• Exchange semantics. If you are not an exchange, always use for as the bet side and ignore against.
• /price_and_stake. Prices and stakes normally travel in the offers field of your /events response. Implement this endpoint only if your odds move faster than we poll that one; we then call it at a rate agreed with you.

2.0.3 Identifiers

You may use your own internal names for leagues and teams, provided they are consistent and descriptive enough for us to match them against events in our system.

IDs are different. Where an object has an id field, it must be the MollyBet ID, not your internal one. These can be obtained from the MollyBet API data feeds. If you do not have the MollyBet ID for something, send null rather than substituting your own.

The one place your own identifiers belong is the selection_id field of each offer. Whatever you put there is passed back to you verbatim when we place a bet.