Prediction Markets API

This document contains all the information required to properly implement applications using our Prediction Markets API.

Prediction Markets API - Starter Guide

Welcome to the FinFeedAPI Prediction Markets developer documentation. This document contains all the information required to properly implement applications using our Prediction Markets API.

Overview of the APIs

3 interfaces can be used to access FinFeedAPI Prediction Markets:

APIDataCommunicationDescription
RESTfulLive and HistoricalRequest-responseStateless API provides comprehensive access to prediction market data.
JSON-RPCLive and HistoricalRequest-responseAlternative RPC interface compatible with the REST endpoints for read-only access.
MCPLive and HistoricalTool callingHosted MCP server for AI agents and tools accessing prediction market data through the /mcp endpoint.

SDK

Our Software Development Kit (SDK) is available on GitHub at https://github.com/api-bricks/api-bricks-sdk. We strongly recommend using our tested libraries rather than creating new ones. If you decide to create your implementation or modify the existing one, we encourage you to create a Pull Request to our main repository with the proposed changes. We will review and potentially include your code in our official repository for use by other users.

In the repository, you can find libraries or examples for languages or environments like:

  • Python
  • R
  • Matlab
  • C#
  • C++
  • .NET
  • Java
  • Ruby
  • Go
  • JavaScript
  • TypeScript
  • Node.js
  • PHP
  • Haskell
  • Objective-C
  • Swift

Security

The use of encryption is mandatory for all prediction market endpoints to ensure the security of trading operations. We implement industry-standard security protocols and best practices.

All endpoints use certificates signed by Trusted Certification Authorities.

Standards and conventions

This section represents used standards and conventions across all documents and APIs.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Variables naming

All variables are named using the Snake case (or snake_case) naming convention. This means that words are separated by a single underscore _ character, no spaces are used, and letters are lowercase.

Market identifiers

Markets are identified using unique market IDs. These IDs are immutable and should be used for all market-related operations. For example, "PM_BTC_2024" for a Bitcoin price prediction market for 2024.

Numbers precision

Numbers in our platform can have a maximum of 19 digits overall, with up to 9 decimal places. For aggregate values (like total market volume), we allow up to 38 digits overall, still with a maximum of 9 decimal places.

Time

For all input and output time values ISO 8601 standard is used.

Format specifierDescription
yyyyThe year is a four-digit number.
MMThe month, from 01 through 12.
ddThe day of the month, from 01 through 31.
HHThe hour, using a 24-hour clock from 00 to 23.
mmThe minute, from 00 through 59.
ssThe second, from 00 through 59.
fffThe milliseconds in a date and time value.
fffffffThe ten-millionths of a second in a date and time value.

Input time values are parsed using the following formats:

  • yyyy-MM-ddTHH:mm:ss.fffffff
  • yyyy-MM-ddTHH:mm:ss.fff
  • yyyy-MM-ddTHH:mm:ss
  • yyyy-MM-ddTHH:mm
  • yyyy-MM-ddTHH
  • yyyy-MM-dd
  • yyyyMMddTHHmmssfffffff
  • yyyyMMddTHHmmssfff
  • yyyyMMddTHHmmss
  • yyyyMMddTHHmm
  • yyyyMMddTHH
  • yyyyMMdd

When time zone information is not supplied, we will assume the UTC zone.

Output time values are formatted using the following patterns:

  1. yyyy-MM-ddTHH:mm:ss.fffffffZ
  2. yyyy-MM-dd

All time values we provide are UTC zones. Do not assume otherwise.

Service StatusGitHub SDK