TokenForge API explained
Last updated
Last updated
The Architecture of our Services is splittet into 5 different areas and thus 5 different APIs:
TokenForge Core Backend (PIM, DCP, CDP)
TokenForge MediaService (DAM)
TokenForge On-Chain API
TokenForge Auction Engine
TokenForge Auth Service
Why do we run multiple APIs and not a single big one? The answer is quite simple: we believe in Separation Of Concerns. Also, not every single customer is interested in all the problems we aim to solve. For some customers, only our OnChain API will be of interest, while others will use our other APIs to run an NFT marketplace.
For each individual service we provide a REST API, while for certain services we also provide GraphQL.
Our Core Backend covers all the aspects of an eCommerce-Platform:
CDP → Customer Data Platform
PIM → Product Information Management
DCP → Digital Commerce Platform for B2B and B2C
KYC & AML → Identity Management and anti money laundering policies
The Core Backend is the space where the whole commerce around a regulated token-commerce is happening. It is the place where customer data lives, where products can be created, managed and eventually purchased, where all order management takes place in conjunction with a comprehensive Administration Dashboard.
In addition, configuration for payment methods, tax services, external mail providers, KYC and AML services, and many other tools and interfaces are also part of the TokenForge Core Backend.
In simple words: the Core Backend is the adapter into the *Web2-*part of the commerce world. Conversely, this means that all blockchain-relevant processes do not take place here.
Our Chain-API, in other words ”The” TokenForge-API, is the place where all the tokenization is actually happening. Moreover, it offers an easy entry point into the world of Blockchains, SmartContracts and many other aspects around Decentralization.
At the time of writing, the TokenForge Chain API covers the following aspects:
Creation of SmartContracts
Import of SmartContracts (ERC20, ERC721, ERC1155)
Creation of managed (EU-speech: “hosted”) Wallets, organized in Vaults
Broadcasting and signing of Transactions:
send native tokens like ETH, AVAX or MATIC
transfer custom Tokens (ERC20, ERC-721, ERC-777, ERC-1155)
mint Tokens
and even
execute custom methods according to a custom ABI
The signing with a managed Wallet is always possible in order to create transactions out of your Backend.
Monitoring of Transactions for a specific wallet or a specific smart contract
Certain metrics of NFT-collections
fetching a history of specific NFTs and/or wallets
collecting all wallets which has been interacted with certain smart contracts
Read and Write-Access to decentralized storage like IPFS and Arweave
Apart from that, we offer a huge suite of SmartContracts that can be used as base contracts for almost any purpose that we have seen recently:
Security Tokens according to ERC-1400 and even eWpG (German Electronic Securities Act)
NFT (ERC-721, ERC-1155)
Access-Control and Permissions Management (e.g. WhiteListing or Operator based actions)
Marketplaces
Staking Opportunities
Vaults like ERC-4626
There is nothing more frustrating than an active live auction in the last 60 seconds and no one can participate any more because the network is congested or the servers are overloaded.
That's why we're building the TokenForge Auction Engine as a separate, loosely coupled service that relies on completely different technical capabilities, with a strong optimization for performance. It can't do much, but it can do it right!
Its purpose is dead simple: it only covers auctions and handles biddings accordingly within a high performance environment. In return, it can send fluent data streams into your UI in order to show current and last bids.
Usually, products that you can buy are represented by at least one image. Depending on the type of product, such as audio NFT, other files can be components of the purchase:
the audio file itself
a video
PDF files with further descriptions or as a manual
Some of these files, such as thumbnails, should be stored with public access so that anyone can access them, including unauthenticated users and even search engines. Other files can be downloaded only by those who have purchased the file and who are currently token owners (”unlockable content”).
Furthermore, to meet today's user demands, it is very important to render content in general as well as images in particular quickly and in an optimized manner into the UI. For this we need different image sizes depending on whether we show the thumbnails in the search, or the small round avatar of a creator, or the large detailed view of a concrete item. We also have to take into account the Retina displays of modern smartphones here, which require double the resolution.
Although there are already appropriate service providers for this in the conventional web world, we see a major challenge in the NFT area in particular:
It makes a huge difference whether my online store offers “only” 120 products (e.g. clothes) in 5-10 different product variants each, or whether I'm dealing with big NFT collections that already come with 10,000 monkeys and 15,000 turtles and 8,500 other mutant stuffed animals.
In addition, decentralized storages like IPFS are very slow and require further caching so that the user experience is not disrupted.
Traditional DAM providers (DAM = Digital Assets Management) can almost offer all of this, but then they become very expensive on the one hand. On the other hand, many of these DAM providers rely on US storage or hosting providers, which many European customers consider "problematic" for a variety of reasons.
Be it related to sustainability, be it related to GDPR or other concerns: TokenForge can help here with its own solution.
Our MediaService is a GDPR compliant DAM provider optimized for online stores in general as well as NFT marketplaces in particular. Built by developers for developers!
The TokenForge MediaService can be used on top of Cloud Storage like GCP or AWS in conjunction with Cloudfront, but it can also be used standalone without them within your own specific data center or just our Germany located hosting partners.
The API-Documentation for the MediaService can be found here:
