Application-Specific API

An exciting recent development has been the development of Application-Specific API server implementations. These are typically self-hosted rather then provided by a third-party. The benefits of this specific approach is that the API Server is user-configurable to only store and index the domain-specific Transactions as defined by the Application Developer. I.e. the Application-Specific API Server serves as a local cache and searchable database of only the Transactions that the developer explicitly inserts into it.


Figure 1: Connecting via an Application-Specific API Server

Figure 1: Connecting via an Application-Specific API Server

What is immediately obvious is that we have introduced yet another level of indirection to our architecture. This should not be a problem since what looks like additional complexity is actually a commodification of infrastructure the Application Developer would have had to build themselves anyway.

An additional benefit of this new crop of Application-Specific API Servers is that at least one of them has an SSE (Server-Side Event / Socket Stream) API on the way. This means we can build reactive applications and properly respond asynchronously to state-change events.

At the time of writing there are three implementations of this type of API Server.

Server Developer Project Name URL
_unwriter (@_unwriter) TXT
MatterPool ( TXQ
LibItx (@libitx) TXBox

The Application-Specific API Server implementations have some variations in their feature-sets. The following is a quick comparison of feature support across the above implementations:

Feature TXT TXQ TXBox
Store sent Transactions * * *
Store unsent(offline) Transactions *
Transaction Metadata * * *
Database SQLite Postgres Postgres/MySQL
Auto TX Write to Miner API *
TX Read/Update from Miner API * * *
Web Console *
SSE (Server-Sent Events) (pending)
Merchant-API request logging * *
Implementation NodeJS NodeJS Erlang

Installation / Setup

For this example I will be using the TXT Application-Specific API Server. This is not an endorsement. The reader is encouraged to look closely at all three implementations. These are early days and more implementations of this architectural type are likely to emerge.

  • get docker container
  • run locally
  • verify with web console


  • broadcast TX to miner API.
  • send same TX to ASA
  • query ASA for TX status
  • lookup TX via web console