A prediction market is an exchange where people can trade contracts based on the outcome of future events. Think of it like a stock market, but instead of buying shares in a company, you buy "shares" in an outcome, like "Candidate A will win the election" or "The Fed will raise interest rates next quarter." The price of a share at any given moment reflects the market's collective belief in the probability of that outcome occurring.

Participants buy shares in outcomes they believe are likely and sell shares in outcomes they believe are unlikely. The price of a share fluctuates between $0.00 and $1.00 (or 0% and 100%) based on supply and demand. If an outcome occurs, the shares for that outcome pay out at the maximum value ($1.00). If the outcome does not occur, those shares become worthless. This financial incentive encourages participants to make well-researched trades.

Their primary benefit is as a forecasting tool. By aggregating the diverse knowledge and opinions of many individuals into a single, real-time price, prediction markets can often produce more accurate forecasts than individual experts or traditional surveys. This phenomenon is often called the "wisdom of the crowd." Businesses, researchers, and governments use them to gauge sentiment and predict trends.

Real-money markets (like Polymarket or Kalshi) involve trading with actual currency, creating a strong financial incentive for participants to be correct. Play-money markets (like Manifold) use a virtual currency with no real-world value. While the direct financial stakes are lower, play-money markets are excellent for fostering discussion, learning trading mechanics, and making predictions on a broader range of topics without financial risk.

Our endpoints support multiple response formats for your convenience, including application/json and the high-performance binary format application/x-msgpack. You can specify your desired format via the Accept header in your request.

You can retrieve a complete list of all supported exchanges and their corresponding exchange_ids by making a GET request to the /v1/exchanges endpoint. This will also provide a description and website for each platform.

The API provides a wide array of time periods for OHLCV data, ranging from one second (1SEC) to five years (5YRS). You can fetch a full list of available period_ids from the /v1/ohlcv/periods endpoint.

Endpoints that list markets, such as /v1/markets/{exchange_id}/history, use pagination. You can use the page and limit query parameters to navigate the results. You can request up to 1,000 markets per page.

A market_id is a unique identifier for a specific tradable outcome on an exchange. For a binary market, you will see distinct IDs for each potential result (e.g., market-question_yes and market-question_no), as each is its own tradable asset.

The endpoint returns a list of all supported exchanges. For each exchange, you will receive its unique exchange_id (e.g., "POLYMARKET"), a brief description, and its official website URL.

The /active endpoint specifically lists markets for an exchange that are currently open and available for trading. The /history endpoint provides a complete, paginated list of all markets for that exchange, regardless of their status (Open, Closed, or Resolved).

You should use the /current endpoint when you only need the single most recent trade and the single most recent quote for a market. Use the /latest endpoint when you need a list containing several recent trades and quotes to get a broader view of the most recent activity.

The order book snapshot provides the current state of the market's depth. The response contains two lists: one for all open sell orders (asks) and one for all open buy orders (bids) for that specific market outcome.

To get historical data, you call the /v1/ohlcv/{exchange_id}/{market_id}/history endpoint. You must specify the period_id (e.g., 1DAY) and can optionally include time_start and time_end query parameters in ISO 8601 format to define the exact date range you need.

Yes, FinFeedAPI offers custom subscription plans tailored to meet specific data requirements and business needs. If your organization requires specialized data sets, higher rate limits, or unique integration support beyond the standard subscription offerings, you can reach out to our sales team to discuss a customized solution.

Yes, it's possible to have multiple API keys for the same subscription. In the Customer Portal, navigate to API Keys > Create Standard API Key. It is important to note that the existence of each additional API Key for a subscription (enabled or disabled) above the plan quota is charged 1 USD per day, with a minimum of one day.

Using multiple API keys helps improve security and manageability by allowing separation between environments (e.g., development, testing, production), tracking usage per product or service, isolating potential issues, and simplifying key rotation without impacting unrelated systems.

Yes, you may have multiple subscriptions.

Multiple subscriptions are commonly used when:

• The software is shipped to multiple third-party's by the customer (eg. self-hosted software)
• To separate environments inside the company (development, testing, staging, production)
• To separate multiple independent production sites (Europe, Asia, etc)
• To separate multiple teams inside the company working on different features or products

Yes, please do!

1. Sign in on the GitHub
2. Fork our main GitHub repository: https://github.com/api-bricks/api-bricks-sdk
3. Work on the changes and push them into your forked repository
4. When you are ready to share the changes with us. Create "Pull Request” to our main repository with a short description of the changes.

Yes, you can use our data to display graphs, charts, or tables. The simplest way is to plug our data into any third-party charting library, for example:

• https://www.highcharts.com/
• https://www.amcharts.com/
• https://www.vobcocharts.com/demos/getting-started
• https://plot.ly/javascript/box-plots/
• https://canvasjs.com/javascript-charts/candlestick-line-chart/
• http://techanjs.org/
• http://recharts.org
• https://uber.github.io/react-vis/examples/showcases/plots
• https://developers.google.com/chart/interactive/docs/gallery

We do not have a special plan for such cases, however we will be happy to speak with you to discuss your requirements and the best plan & pricing that will fit your needs!

Yes, we have a Status Page at: https://status.finfeedapi.com

We do not support custom timezones, data is always processed in the UTC.

If you need to operate in the custom timezone then input and output values should be converted on the client-side before a request is sent to us or output data processed.

In the corner cases like OHLCV data on the higher than 1HRS periods (eg. 1DAY), you should execute queries only to the 1HRS period at the maximum and assemble higher periods like 1DAY on the client-side, as our 1DAY always starts and ends at the UTC midnight.

Yes, CoinAPI provides Service Level Agreements (SLAs) tailored specifically for enterprise clients. These SLAs define key performance and reliability metrics to support mission-critical applications, including:

• Guaranteed uptime and availability targets
• Maximum response time thresholds
• Dedicated support availability and escalation paths
• Incident response and resolution timelines

SLAs are structured to meet the needs of high-throughput trading platforms, institutional users, and large-scale data consumers who rely on consistent and predictable API behavior.

To discuss SLA options and terms, please contact our sales team.

You can generate an API Key via the Customer Portal. Once you have your API key, you can begin making requests immediately.

The actual integration time depends on the complexity of your project:

• For simple use cases, setup can take as little as 5 minutes
• For more complex systems (e.g., production-grade trading platforms or data pipelines), integration may take several days

Our SDKs, documentation, and sample code are designed to help accelerate the process, regardless of your environment or programming language.

To stay informed about service status, outages, or scheduled maintenance, CoinAPI provides a dedicated status page. We recommend subscribing to email notifications directly on the page to receive real-time alerts.

If you encounter an issue that is not reflected on the status page or disagree with its current content, please report it using our support form.

Yes, FinFeedAPI provides a standard Service Level Agreement (SLA) for all paid plans. This covers key performance metrics such as uptime, availability, and support responsiveness.

If your organization requires a custom SLA, this is available through our Enterprise Plan. Custom SLAs can include specific commitments around latency, incident response times, and dedicated infrastructure options.

To discuss custom SLA requirements, please contact our sales team.

Yes, you should file a support ticket whenever an issue occurs. This is essential even if the problem seems temporary or intermittent.

Here’s why:

• Your support SLA (if applicable) is only activated when a ticket is submitted.
• Without a formal ticket, we cannot guarantee prioritization, investigation, or tracking of the issue.
• If your plan does not include a service-level SLA, we do not monitor or proactively respond to issues unless they are reported.

For customers with custom SLAs, we track specific metrics and build infrastructure to meet those guarantees. For all other users, we rely on incoming tickets to understand what matters to your business.

Our process:

• We continuously monitor infrastructure and act on system-level issues.
• However, without ticket input, we may not detect or be accountable for individual cases that affect your workflow.
• If needed, we expand monitoring and internal metrics based on patterns in submitted tickets.

You can submit a new ticket here.

Yes, FinFeedAPI offers integration assistance as part of our Enterprise tier. This support can be tailored to your technical architecture, workflow requirements, and business objectives.

If you’re interested in hands-on onboarding, architecture reviews, or guided implementation, please contact our team to discuss the best setup for your use case.

Yes, to use credit-based services like Flat Files or REST API access, you must preload usage credits to your account. Here's how it works:

Preloading Credits

• Once you link your credit card, you’ll need to manually add credits through the Billing > Add Usage Credits section in your dashboard.
• Optionally, you can enable Auto Recharge, which automatically tops up your credits once your balance falls below a defined threshold.

How Charges Work

• Credits are prepaid, meaning you load your account before downloading data.
• The cost of your activity (e.g., API calls, Flat File access) is deducted from your available credit balance.

Processing Time

• Credit top-ups are processed in near real-time.
• Your available balance updates almost immediately after the credit card is charged.
• Only exception: crypto payments may have a short delay (up to 1 hour) due to blockchain confirmation times.

Usage Credits Documentation

If you are finding that you are always requiring more daily requests, one way to circumvent this is by enabling Spend Management and Auto Recharge, wherein you can go above the limit of requests per day.

You may enable Spend Management and Auto Recharge through the Customer Portal

You may read more about these features here:

• Spend Management
• Auto Recharge

If your subscription has a hard limit, exceeding your daily REST API quota will trigger an HTTP 429 Too Many Requests error response. This means no further requests will be processed until your 24-hour rolling window resets.

For soft-limited plans, we may allow overages temporarily, but we will contact you if usage consistently exceeds your plan limits, prompting an upgrade discussion.

How to Monitor Usage:

• Use our Subscription Management API to track usage and quotas in real-time: View Subscription API Docs
• Review HTTP status codes and errors

The reason why response headers are not always present in the API responses is that, in some cases, we are unaware of their specific usage or requirements. To ensure that we promptly respond to your API calls and avoid unnecessary delays, we choose to provide a response without including the response headers. This decision is made with the intention of optimizing the operation of our API. By selectively excluding the inclusion of response headers in every request, we can enhance the overall performance and efficiency of the API.

It takes a while to verify the current usage as for the very first call for a given client we do not have a rate limit then yet. Once the request is made, we start the rate limit verification process In the background. We may then in the meantime process many requests for this client and at some point we append the result of current usage to the header. All requests that were made during that process are also included in the limit after some time.

For example (each bullet point representing a request made):

• Request (no info about clients usage)
• What's the usage? Starting the verification
• Request
• Request
• 5 requests used today (those 3 above are not counted yet), appended to the header
• Request (5 used)
• Request (5 used)
• Request (5 used)
• Request (5 used)
• Request (10 requests used today)

You can view your past API usage directly in the FinFeedAPI Customer Portal:

1. Log in at: https://console.finfeedapi.com
2. Navigate to the Usage Explorer tab
3. Review your usage breakdown by using the Metrics available on the dropdown and filter by selecting a date range.

Additionally, for real-time tracking, you may refer to the Quotas and Limits section of the Customer Portal.

By default, FinFeedAPI limits responses to 100 items per request. However, you can increase this by using the limit query parameter.

• The maximum value for limit is 100,000 items
• If you request more than 100 items, every 100 items counts as one request toward your usage quota

Example:

bash

GET /v1/trades?limit=500

This call will return up to 500 trades and count as 5 requests in your quota.

Use this option when you need to retrieve large result sets efficiently, but be mindful of your daily request limits.

REST API usage is measured not by the number of API calls alone, but by request credits, which depend on how much data each call retrieves.

Key points to understand:

• FinFeedAPI uses a rolling 24-hour window to calculate usage
• Each data request credit counts as one "request"
• Some API endpoints return multiple data points per call
• If the limit parameter is used, every 100 items returned counts as one request credit

Example:

If you make a single call to retrieve 10,000 OHLCV records using limit=10000, that counts as 100 requests (10,000 ÷ 100), not just 1.

So, while your logs may show only 85 API calls in a day, your total usage could reflect over 10,000 request credits—especially when pulling large data batches.

This can lead to exceeding the daily request quotand result in HTTP 429 Too Many Requests errors.

FinFeedAPI uses a credit-based system for REST API requests. The number of request credits consumed depends on how many data items you retrieve in a single call.

How it works:

• If you do not use the limit parameter, the default is limit=100, which counts as 1 request
• If you do use the limit parameter, every 100 data items returned counts as 1 request

Example:

bash

GET /v1/ohlcv/BINANCE_SPOT_BTC_USDT/history?limit=1500

This call returns 1,500 items, which counts as 1500 ÷ 100 = 15 requests

Additional tips:

• limit minimum: 1
• limit maximum: 100,000

Yes, FinFeedAPI uses a credit-based model, but here's how the request-based billing works with the limit parameter:

How Credit Consumption Works:

• Each successful API request counts as at least 1 request.
• If your request includes the limit parameter:
  • Every 100 data points = 1 credit (rounded up).
  • Example: limit=200 = 2 credits, limit=1 = still 1 credit.

Even if you only request 1 data point (limit=1), it still triggers a full request and uses 1 credit, because that's the minimum unit for billing.

Because the API is S3-compatible, it uses standard HTTP status codes for responses. If an error occurs, you will receive a standard error code (e.g., 403 for Forbidden, 404 for Not Found) along with a detailed XML body describing the nature of the error, which is consistent with Amazon S3 error responses.

We built our own CDN network with nodes directly distributing data between each other via the fastest routes. Any existing CDN solutions are targeted on caching which is not applicable to financial data.

Your sensitive information is stored inside the service provider, which is constantly audited and certified as a PCI-DSS Level 1 Service Provider. This is the most stringent level of certification available in the payments industry. To retain the certification, a payment provider must use world-class security tools and techniques to maintain a high level of security.

You may delete the compromised key and generate a new one on the API Keys section of the Customer Portal. This way, the compromised key will no longer be active for use and will not affect your subscription limits.

FinFeedAPI operates a globally distributed infrastructure with low-latency data centers in the following locations:

• AWS Regions: us-east-1, eu-central-1, eu-west-1
• Colocated Sites:
  • USA: Chicago, New York
  • UK: London
  • Poland: Warsaw
  • Asia: Tokyo

Latency Behavior:

• Real-time data (via REST /current, WebSocket, FIX) is delivered from the site you’re connected to, routed using GeoDNS to the closest available server.
• Average latency for public endpoints is ~20ms.
• On Enterprise plans, customers can achieve sub-1ms latency using direct connections or AWS VPC Peering.

Historical data (via REST /history and Flat Files) is consolidated across all regions to produce a single, globally consistent dataset. This reduces geographic discrepancies but can be impacted by replay process constraints.

Learn more about optimizing connectivity or request direct site access by contacting our support team.

Certificate validation errors typically occur when your system lacks updated CA (Certificate Authority) certificates. Here’s how to resolve it based on your operating system:

On Windows:

• Ensure your Windows Updates are fully installed, as CA certificates are updated through the standard update process.

On Ubuntu/Debian Linux:

• Run the following command to refresh your certificate store:

sql
sudo update-ca-certificates

Alternative Option:

If updating certificates isn't feasible, you may connect via an unencrypted HTTP endpoint—though this is not recommended for production due to security concerns.

For production environments, we recommend using HTTPS with properly updated CA bundles.

You can integrate CoinAPI with MATLAB using multiple approaches, depending on your preferred development environment:

1. Java SDK integration: Use Java libraries from MATLAB – Learn how
2. .NET SDK integration: Call .NET libraries from MATLAB – Guide here
3. Python SDK integration: Use Python libraries (like FinFeedAPI Python SDK) within MATLAB – Instructions
4. Use webread() for direct API access: The webread function can call RESTful APIs and automatically convert JSON into MATLAB objects. – See how

This flexibility allows you to access CoinAPI’s market data or exchange rates from within MATLAB for trading strategies, analysis, or research.

FinFeedAPI is language-agnostic, you can use it with any programming language that supports HTTP requests and JSON parsing.

To make development easier, we provide official SDKs and code examples in our GitHub repository for the following languages:

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

These SDKs cover common integration patterns for REST, WebSocket, and FIX APIs.

All timestamps returned by FinFeedAPI, across REST, WebSocket, and FIX protocols, are standardized to UTC (Coordinated Universal Time).

This applies to:

• Historical data (e.g., OHLCV, trades)
• Real-time streams
• Metadata and time range filters

You can explore our official SDKs, integration examples, and client libraries on GitHub.

The repository includes:

• Sample code for REST, WebSocket, and FIX APIs
• SDKs in multiple programming languages (e.g., Python, Java, C#, Go, etc.)
• Tutorials and usage demos

This is the best place to get started with real-world examples and accelerate your integration process.

FinFeedAPI does not block or restrict VPN usage, and in most cases, a VPN should not impact your API connection. However, several factors can influence performance:

What to Consider When Using a VPN:

1. VPN Quality
   • Low-quality VPNs may block API traffic, limit bandwidth, or introduce instability.
2. Server Location & Latency
   • The physical distance between you, the VPN server, and FinFeedAPI infrastructure can increase latency.
   • In countries with internet restrictions (e.g., China), a VPN may be required to access our services
3. VPN Configuration
   • Ensure your VPN allows outbound HTTPS traffic and isn’t blocking specific ports or protocols used by FinFeedAPI
4. Your ISP
   • Even with a VPN, poor underlying internet quality can cause timeouts or dropped connections.

Troubleshooting Tips:

• Temporarily disable the VPN to check if it’s causing the issue
• Switch VPN servers or providers for better performance
• Update your VPN software to the latest version
• Contact your VPN provider if API traffic is being throttled or blocked

If problems persist, please contact our support team for assistance.

If you're experiencing connection issues with FinFeedAPI please follow the steps below before submitting a support request:

1. Check FinFeedAPI Status Page to confirm there are no ongoing service disruptions.
2. Verify DNS resolution Use the dig command to check domain name resolution: A correct response includes an ANSWER SECTION with IP resolution like: If the ANSWER SECTION is missing, this indicates a DNS resolution issue.

pgsql

dig [domain name here]

lua

;; ANSWER SECTION:
fix.coinapi.io. IN CNAME api.coinapi.io.
api.coinapi.io. IN CNAME api.coinapi.net.
...
hdc1-enc-02-bay-08.coinapi.net. IN A 185.204.225.28

1. Check TCP connectivity Use nc to verify port access: Expected output: If the command fails, analyze the TCP connectivity on your side before contacting support.

cs
nc -v [hostname] -p [port]

css

Connection to fix.coinapi.io 3302 port [tcp/*] succeeded!

1. Test encryption behavior Try switching between HTTPS and HTTP endpoints. If the issue appears only with one type, document that in your report—it helps isolate encryption-related errors.
2. Capture a PCAP dump for analysis Use tcpdump to capture traffic. Adjust the port according to the API protocol:
   • REST or WebSocket API:

bash

tcpdump -i [interface] port 80 or port 443 -w dump.$(date +"%Y%m%dT%H%M%S").cap

• FIX API:

bash

tcpdump -i [interface] port 3302 or port 3303 -w dump.$(date +"%Y%m%dT%H%M%S").cap

1. Analyze the PCAP file before submission Ensure:
   • CoinAPI is on the other end of the connection
   • The problem is not caused by internal proxies, gateways, or firewall misbehavior
   • The capture was performed from a system directly connected to the internet (not behind NAT if possible)
2. Submit a support request Use the "API Issues" form at: https://support.coinapi.io/ (https://support.coinapi.io/) Include:
   • Accurate problem description with UTC timestamps
   • Results of the DNS (dig) and TCP (nc) checks
   • A PCAP file with analysis details
   • Set the issue priority according to impact:
     • Urgent – Production system down
     • High – Production system impaired
     • Normal – Feature/system partially affected
     • Low – General guidance or questions

This structured process ensures the support team can respond efficiently and effectively to network-related issues.

If you're receiving an "Invalid API Key" error shortly after generating a new key, this is expected behavior for a brief period.

FinFeedAPI operates multiple geographically distributed and independent server sites for high availability. Because of this architecture, it may take a few minutes for your new API key to fully propagate across all regions. This short delay is a trade-off for ensuring there is no single point of failure in our infrastructure.

What to do:

• Wait a few minutes and retry your request
• Do not regenerate a new key unless the issue persists for more than 5–10 minutes
• If the problem continues, contact support

To access FinFeedAPI via FIX protocol, you can use a standard Market Data API key. Here's how to generate it:

How to Generate Your API Key

1. Log in to your Customer Portal
2. In the left-side navigation, go to API Keys
3. Click Create Standard API Keys
4. Your new API key will be valid for both REST/WebSocket and FIX interfaces

You can also disable or delete keys from the same portal interface as needed.

The WebSocket error code 1006 typically indicates that the connection was closed abnormally, without a proper closing handshake. This can be caused by several external or local factors:

Common Causes:

• Unstable Internet Connection: Temporary drops or packet loss can trigger disconnections.
• Firewall or Proxy: Network security layers may block or interrupt persistent WebSocket connections.
• Client-Side Crashes: Application errors or memory leaks could cause forced shutdowns.
• Timeouts or Rate Limits: Ensure you’re not exceeding subscription limits or timeouts set by your environment.

Troubleshooting Tips:

• Ensure a stable and continuous internet connection.
• Whitelist WebSocket traffic in your firewall or proxy settings.
• Review your application logs for crashes or timeout issues.
• Consider implementing reconnection logic in your WebSocket client to handle disconnects gracefully.

If the issue persists and you're on a corporate network, consult your network administrator or reach out to our support team for assistance.