Oo someone's lookin to get fancy. Build using the same APIs our SDK, console, and team uses.

Our Layer 0 (aka L0) connects TIKI's decentralized data licensing infrastructure to the internet. Simply put, leverage data licenses outside the application layer.

The Layer 0 consists of a collection of microservices (with the occasional CDN deployed serverless function) each with a very specific purpose and its own API. If you're looking for a single uniform API, scroll back up, this is not the section for you.


Open API Spec →

The registry is responsible for mapping customer-specific user ids to wallet addresses. It's used by the L0 Index when searching for licenses by user id, and by the SDK for syncing records across devices. Every user registered receives an additional signing key, used to double-sign licenses on behalf of the customer. It also includes a nifty security feature, where companies can leverage their existing application authorization tokens to verify identity on user registration.


Open API Spec →

The index makes all your licenses and title records easily searchable. If you remember back to our immutable data structure, it's powerful for legal consent, but not exactly easy to work with. The index service, creates a normalized version of the data structure with key metadata, making search a breeze. It also, handles turning those pesky binary blocks into pretty JSON for you. These routes will look familiar; they're the endpoints behind our standard (non-advanced) API.


Open API Spec →

The interface for uploading payloads (blocks, public keys, etc.) to our hosted immutable bucket. Yup, doubly immutable 🙄. We use Object Lock with Wasabi Buckets to create a secure hosted backup of all titles and licenses (a bit like when you need a copy of your birth certificate you get a certified copy). These records power the index, but also provide users with long term storage of their licenses, in case they delete your app, break their phone, etc.

Unless you're porting our SDK to a new platform, you can probably avoid this service entirely.


Open API Spec →

JWKS Endpoint ->

The service responsible for dishin out tokens. It maintains a few very simple account details (we don't store unnecessary data, it's kinda a thing of ours) required to construct various access tokens for the other L0 services. As you dig in further you'll come to learn, we use JWTs in a variety of ways. Some routes only require a JWT generated from a public key (no secret) where others go as far to first require a password grant. For example, you must prove your identity to create a new app, a private key on its own won't do. But to request a storage token, you only need a public key (apps and websites are bad bad places for secret keys).

Good luck and have fun!

Don't hesitate to reach our if you get stuck. All of the source is up on GitHub; feel free to open issues. Or pop in our Discord, you'll find the whole team there.