Skip to main content
If you already call the Moralis Web3 Data API, you can move endpoint by endpoint onto Data Feeds. You go from a pre-packaged REST response to the underlying decoded data that produces it, served from a database you own, in real time, with no per-call limits and full control over how you store and query it. This page is the background to read once. When you are ready to move a specific endpoint, go to the endpoint list and pick the one you call today.

​
API vs. Data Feeds: why they are different

The Data API hands you a finished answer. A single call returns a wallet’s tokens, already joined to prices, metadata, and spam flags, shaped into one JSON response. Data Feeds hand you the decoded onchain data that answer is built from, streamed into a database you own. You assemble the answer yourself, which is what gives you no per-call limits, full history, and control over filtering and pricing. That trade has one consequence worth internalizing before you start:
A Data Feed reconstructs an endpoint, it is not a byte-for-byte copy of the old response. The same facts are there, but they arrive as raw rows across a few datasets rather than one pre-joined object. You do the join (usually one SQL view), and you decide what to do about the off-chain extras.

​
Start with the model, once

Two concept pages explain how Data Feeds work, so every recipe links here instead of repeating it. Read these first and the per-endpoint migration sections go quickly:
  • What are Data Feeds? The one data lake, and the ways to consume it (Kafka-compatible / AMQP / SQS-compatible clients, REST / Arrow Flight, the sink into your own database, or query engines via Iceberg).
  • Data Feeds vs. the REST API The fidelity model: a Data Feed reconstructs an endpoint from raw onchain data, it is not a byte-for-byte copy of the old response.

​
The schema gotchas to plan for

These are the differences that surprise people first. Each recipe’s migration section states the answer for its own endpoint(s), but the pattern is always one of these:

​
How to read the fidelity of a migration

Every field-mapping table classifies each output value so you can plan with confidence. Throughout, you will see three labels:

​
Find your endpoint

When you are ready, the Map endpoints to recipes table maps every covered Moralis REST endpoint to the recipe (or combination of recipes) that replaces it, ordered by usage. Migration details live on the recipe pages themselves: each recipe has a “Migrating from the REST API” section with the field-by-field mapping, the required recipe combination, one reconstruction query, and the endpoint-specific gotchas. One page per dataset: the recipe is the single source of truth. New to Data Feeds entirely? Start with the quickstart to get live data flowing into your own database in about ten minutes, then come back and migrate your endpoints. And skim Gotchas & troubleshooting before your first run; it lists every known failure point with the fix.

​
How each migration section is structured

Every recipe’s “Migrating from the REST API” section follows the same shape, so once you have read one you can skim the rest:
  1. The REST endpoint(s) it replaces, and whether you need this recipe alone or a combination, stated up front, with links to the other recipes you need.
  2. Field mapping reference, the per-field table with the fidelity label.
  3. One reconstruction query, the SQL view that rebuilds the old response shape.
  4. Good to know, the endpoint-specific gotchas worth knowing before you ship.