Defined API V2

Defined’s API is improving! 🎉

We are ready to release some large improvements to our public api. Our website at has been running on this API for over a month now in order to test the quality, and we now think it’s ready for prime time!

Over the past year our API has grown in size, both by number of developers contributing, and total number of fields resolved. We process billions of requests monthly and pride ourselves on providing a highly reliable and fast suite of endpoints for you to build on.

This update constitutes a complete overhaul of all the backend infrastructure, for both realtime sockets and transactional http requests.

We want this upgrade to be as painless as possible for you to integrate into your applications, so we’ve kept the schema backwards compatible. You should be able to simply change the URL, and then start making requests.

Also, we are releasing the all new sdk for use in your projects! It will help you make requests against the Defined API, as well as provide generated types and schema GraphQL.


Our existing API was built on a hosted GraphQL platform called AWS Appsync. We had multiple disconnected Appsync GraphQL APIs. Each query field was implemented by a lambda, and this resulted in thousands of lambdas across our environments.

Actual photo of me describing the problems to other engineers at defined

Actual photo of me describing the problems to other engineers at Defined

Api V1 Problems

  • Scaling. We have one gigantic schema.graphql file per appsync graph, as we add more features and developers this gets harder to manage.
  • Appsync has no schema registry, this meant that we had to build a hacky version ourselves. Otherwise an accidental removal of some fields could cause outages.
  • Tons of boilerplate. This greatly slows down development speed. We have to create a lot of resources on AWS just to deploy a new query / field. What this means is we usually overload the fields we already have with far too many inputs / outputs.
  • Each query is it’s own lambda function. This contributes to the boilerplate. It also makes nesting of resources very difficult, which is one of the main benefits of using graphql in the first place
  • Not very flexible. You can’t get at the internals of the graphql api at all, poor support for directives, lots of AWS quirks.
  • Almost no observability. There was no easy way to implement metrics for both user facing query statistics or for performance monitoring.
  • We had a “private” api and a “public” api, which meant that it took longer for good features to hit the public api, and there was a lot of duplicated effort.


Everything was recreated using a federated GraphQL supergraph. We split out parts of the greater schema into many subgraphs. This allows developers to modify graphs in isolation, much more rapidly and with more confidence.

By removing Appsync, we are able to track fine grained metrics about how long each field takes to resolve, as well as make use of the best features of GraphQL, like directives, custom scalars, nested fields, much faster subscriptions and many more. We can now more efficiently cache different fields as well, resulting in faster responses.

What does this actually mean to you? Probably not a lot, aside from shaving a few hundred MS off the response times, more stable socket connections and easier to integrate authorization. The existing schema should work as a standalone replacement.


We’ve also made an effort to improve our documentation at We switched to an entirely new platform and overhauled it with guides and an API reference. This is an ongoing focus of ours to provide the best information on how to use our platform, so please let us know if anything is missing or incorrect.


Our (now) legacy API will remain available until January 1st. After that it will be shut down and all customers will need to move to the new infrastructure.
Now that we have a more scalable and easy to work with system, you can expect faster turnaround on bug fixes, and feature improvements.


Old API was slow, hard to maintain and didn’t offer enough flexibility. Our new API is fast, easy to maintain, and extremely scalable.

Explorer: Explorer

Api url:

Realtime url:

Authentication: Simply provide your api key as the value for the Authorization header. This is the same for both sockets & post requests

Want to try out the Defined Api for your project? Start querying the fastest, most accurate, and most comprehensive api for DeFI/NFT data. Get started for free at

Got any questions?


Join our Discord

Ask questions, share what you're working on and request new features :two-men-holding-hands::two-women-holding-hands: