API Bricks SDK: generated clients for CoinAPI and FinFeedAPI

Two product families, one repository

The API Bricks SDK repository contains SDKs for the APIs of a single vendor, and the README says so plainly. It provides SDKs for the main product families, CoinAPI and FinFeedAPI, and the repository is organised into two main directories, `coinapi` and `finfeedapi`, each containing subdirectories for specific APIs and their associated SDKs or samples.

CoinAPI is the crypto side. Its main website is coinapi.io and its documentation hub is docs.coinapi.io, and the family covers a Market Data API, an Execution Management System in several shapes, an Indexes API, an Exchange Rates API, and a set of flat file processing samples. The protocol column in the table is the interesting one: the Market Data API appears against REST, WebSocket and FIX, and the EMS products are split across REST, WebSocket and FIX variants, including a Managed Cloud REST API, a Gateway REST SDK and a Gateway FIX SDK. The Indexes and Exchange Rates APIs are REST with WS support.

FinFeedAPI is the other side, aimed at traditional and adjacent markets. Its site is finfeedapi.com with documentation at docs.finfeedapi.com, and the family covers a Stock API, an SEC API, Currencies Realtime and Currencies Historical APIs, and a Prediction Markets API, all REST.

So the repository is not one SDK with two back ends. It is a set of clients, one per service and per protocol, grouped by product family. That grouping is the single most important thing to understand before you install anything, because it tells you where to look and what you will be signing up for.

The primary language recorded for the repository is C#, the licence is MIT, and the topics list covers bitcoin, ethereum, ripple, market data, exchange rates and trading APIs.

The directory map, and the redundancy the README admits to

The repository organisation section gives a table of CoinAPI directories with their descriptions, and reading it closely is instructive because the author flags their own uncertainty in three places.

The CoinAPI directories cover the market data API in REST, WebSocket and FIX flavours, the EMS managed cloud management API, the EMS REST and FIX APIs, the indexes REST API, and four exchange rates directories: `exchange-rates-api-historical`, `exchange-rates-api-realtime`, `exchange-rates-api-rest-historical` and `exchange-rates-api-rest-realtime`.

Those four are where the README annotates itself. The realtime one is described as the SDK for the Exchange Rates Realtime REST API, with a note that this might also cover WebSocket or be split, to be confirmed. The historical one carries a note that it is potentially redundant or a more specific version of `exchange-rates-api-historical`. And the REST realtime one is marked as potentially redundant or more specific than `exchange-rates-api-realtime`.

A project that labels its own directories as possibly redundant and possibly to be split is a project mid-refactor, and a user picking a client should read those notes rather than guess from the directory name.

The FinFeedAPI side is tidier, with five directories: `stock-api-rest`, `sec-api-rest`, `currencies-api-rest-realtime`, `currencies-api-rest-historical` and `prediction-markets-api-rest`.

Two more top level entries are worth noting. There is an `mcp/` directory, and there is a `flat-files-api-processing-samples` directory under CoinAPI, described as examples related to processing GZIP+CSV flat files rather than an SDK, which is a different kind of artefact from the rest of the tree.

Where the clients are published, and the packaging gap to watch

The package managers coverage table is the practical part of the README, and it is short enough to quote in full because the differences matter.

For C# there are two NuGet packages, `CoinAPI.REST.V1` for REST and `CoinAPI.WebSocket.V1` for WebSocket, both with version badges pointing at NuGet.

For Java there are two packages hosted on GitHub Packages rather than on Maven Central, `io.coinapi.rest.v1` and `io.coinapi.websocket.v1`, with direct links to the package pages in this repository.

For Python 3 there is one PyPI package, `coinapi.rest.v1`.

That table covers five packages, while the language coverage section lists libraries for Python, R, Matlab, C#, C++, .NET, Java, Ruby, Go, JavaScript, TypeScript, Node.js, PHP, Haskell, Objective-C and Swift, and describes them as libraries that will help you use the API with minimal development effort from those languages. The two lists do not line up, and the packaging table is the one that carries a version and a link.

So the honest reading is that a small set of packages is published for a few languages, while the broader language list describes the SDK directories present in the tree, which you can build or vendor yourself. Anyone planning around a specific language should check the package table first, and a Java user should note that the Maven coordinates come from GitHub Packages, which needs its own repository configuration and its own credentials.

The FinFeedAPI clients do not appear in the packaging table at all, so a FinFeedAPI user has to look at the directory tree and the documentation hub rather than at a published artefact.

OpenAPI specifications are the actual source of truth

The section on OpenAPI specifications explains how the clients relate to their source definitions, and it is the most useful thing in the README for anyone maintaining this code.

OpenAPI, formerly Swagger, specification files, typically named `openapi.yaml` or `openapi.json`, are provided for many of the RESTful APIs in the repository. These files define the API's structure and can be used with various tools for documentation generation, client SDK creation and testing.

The README gives two common locations. A `spec/` subdirectory directly within the API's folder, for example `coinapi/market-data-api-rest/spec/openapi.yaml`. And within language-specific SDK directories, often under an `api/` or similar subdirectory, for example `finfeedapi/sec-api-rest/sdk/java/api/openapi.yaml`.

The variation in location is itself informative. It means the generated clients are produced from the specification files, and the specification is the artefact that matters for a change. If you need to add an endpoint, the workflow is to update the spec and regenerate, not to hand-edit a generated client, and the two example paths show that the spec sometimes sits above the language directory and sometimes inside it.

The README closes this section by asking you to explore the individual API directories for the most up-to-date and specific locations, which is an admission that the convention is not uniform across the tree. For a user, the practical instruction is to look inside the directory of the service you care about rather than assuming a path.

Where this SDK set is the wrong choice

The first wrong-tool case is a multi-vendor data pipeline. Every directory in this repository maps to one product family and one protocol, so if your application also pulls from a second market data provider, you end up with two unrelated client models rather than one abstraction. There is no common interface here, because the packages are per service.

The second is a task that the services do not cover. The SDKs exist to talk to CoinAPI and FinFeedAPI. If the job is a one-off historical query against a public source, a paid subscription with per-request metering may be more than the requirement calls for.

The third is a strict protocol requirement that the table does not satisfy. The FIX clients exist for CoinAPI, but the FinFeedAPI family is entirely REST, and the C# and Java publishing lines are REST and WebSocket only. If your infrastructure is FIX-only and you need equities data, there is no package in this table for it.

The fourth is a Java or Python user who needs a published artefact for the FinFeedAPI side. The packaging table lists five packages, all CoinAPI, and the FinFeedAPI SDK directories have no version or link against them, so the install path is the source tree rather than a registry.

The alternative worth naming is generating your own client from the same OpenAPI specifications with a tool of your choice, or writing thin request code against the documented HTTP endpoints yourself. The difference in approach is that the vendor client gives you a ready made object model, typed parameters and the vendor's own idea of the endpoints, at the cost of tying your code to that object model, while generating from the same specification gives you a client with a shape you control and the same endpoint coverage, and hand-writing gives you full control and no client generation step at all.

Maintenance state and the licence

The last push to the default branch was on 2026-10-20, and the repository is not archived, so the code is being worked on. There are no GitHub releases, which fits a repository whose artefacts are NuGet, PyPI and GitHub Packages packages rather than source archives, and whose versioning lives with each published package.

The licence is MIT, with a `LICENSE` file at the top of the tree. That is a permissive licence with no copyleft obligation, and for a client library it is the arrangement you would want: a commercial application can depend on the SDK and redistribute it without publishing anything of its own. The one qualification is that the code and the service terms are separate. An MIT licence covers the client code, not your right to use the market data, and the data itself is governed by whatever subscription you buy. This is a description of the published terms rather than legal advice, and anyone using it commercially should read the subscription terms alongside the `LICENSE` file.

The `.github/` directory at the top level holds the workflows, and the README closes with an invitation to make pull requests with proposed changes or create an issue, saying the team responds as soon as possible.

Two things a reader should still verify before depending on this. The first is the currency of the directory structure, since the README itself flags exchange rates directories as possibly redundant or pending a split, and a directory that moves is a broken import path. The second is which services your plan actually covers, since the repository carries clients for every product family whether or not a given subscription includes them.

Editorial conclusion

Adopt the API Bricks SDK when you are integrating CoinAPI for crypto market data or FinFeedAPI for stocks, currencies, SEC filings and prediction markets, and you would rather work against a generated client than hand-write the request signing and error handling. Do not adopt it expecting a neutral abstraction across vendors, because every directory in the repository maps to one product family and one protocol, so switching data providers means rewriting rather than repointing. Before you start, check the package table for the exact protocol you need, since the C# packages are split by REST and WebSocket and the Java ones are hosted on GitHub Packages rather than Maven Central, and confirm your subscription covers the endpoints you intend to call.

Frequently asked questions

Official sources

1. api-bricks/api-bricks-sdk on GitHub
2. Issues
3. License: MIT
4. Project website
5. README