Skip to main content

​
What a recipe is

A recipe is a ready-made blueprint that reconstructs one popular Moralis endpoint as a continuous sync into a database you own. Instead of calling an API per request, you run the recipe once and the data lands, and stays current, in your own ClickHouse, Postgres, or MySQL.
Coming from the Moralis REST API? Each recipe maps to one or more REST endpoints. Start with the migration overview for how the API and Data Feeds differ, then use the endpoint list to find the field-by-field guide for the endpoint you call today.
Each recipe ships everything you need to run it:

Sync config

The source data, the projection that shapes it, and the destination wiring.

Schema

The destination DDL: tables, indexes, and materialized views.

Queries

The exact reads that answer the endpoint’s question.
Recipes are blueprints, not turnkey deployments: they show the projection, schema, index layout, and reorg strategy for each access pattern. Lift the pieces you need.

​
How a recipe works

Every recipe is the same three-stage pipeline:
  1. Source: normalized per-block data from Data Feeds. One block carries arrays of every event type (token transfers, native transfers, NFT transfers, swaps, approvals, price updates, and more).
  2. Transform: a projection that expands the arrays you care about into one row per event and shapes them into the endpoint’s schema.
  3. Destination: the rows land in your database, indexed for the access pattern the endpoint serves (by wallet, by token, by pair, …).
The same source event stream can land different ways for different questions: e.g. “balances by wallet” and “balances by token” are the same sync with a different sort key.

​
Schema & flexibility

Every recipe page includes a full schema (the complete set of columns that access pattern can produce), but nothing about it is fixed. Recipes are blueprints you shape to your needs:
  • Select the columns you want. Start from the full wide table and keep only the fields your app reads. The projection pulls just the source fields behind the columns you keep, so trimming the schema trims the work.
  • Select the events you want. Multi-event recipes (like Wallet History) union several event types into one table; drop the branches you don’t need.
  • Choose your keys and indexes. The sort key and indexes are tuned for the headline access pattern; re-key for yours. Optional structures (like the by-topic0 grouping on the log recipes) ship commented-out; enable them only when you need them.
  • Pick your destination types. Adjust column types to fit your warehouse. The shipped DDL flags where precision matters: raw uint256 amounts as text, USD as wide decimals.
In other words: the full schema is a starting point, not a contract. Take the complete shape and pare it down.

​
Destinations

Recipes support three destinations. ClickHouse is the first-class path; it’s the only one that handles live, reorg-safe ingestion: ClickHouse recipes use a collapsing log-table pattern: events land in a wide table, and a companion log table carries one signed row per block. When the chain reorganizes, the log emits a counter-row and ClickHouse collapses the pair on merge, so your tables converge on canonical state without manual cleanup. Read canonical state with FINAL or a sign-aware aggregate, never a bare WHERE sign = 1. Postgres and MySQL recipes write flat, uniquely-keyed event tables and are first-class for historical backfill. For live/reorg-safe ingestion on these shapes, use ClickHouse.

​
Modes

​
Token Prices is the connective tissue

Any “what is this worth in USD” question (a transfer’s value, a portfolio’s worth, a trade’s notional) needs prices. The Token Prices recipe is the shared join target across the accounting, portfolio, and trading use cases. Several recipes (like Wallet History) also fold per-block USD values inline so common reads need no extra join.

​
Recipe catalogue

Recipes are grouped by the API product they replace, so you can start from the API you use today. ⭐ marks the most popular endpoints. Coming from the REST API? Each recipe page ends with a “Migrating from the REST API” section: the REST endpoint(s) it replaces, the field-by-field mapping, and (because Data Feeds are not a 1:1 endpoint swap) the exact combination of recipes you need when one endpoint spans several datasets. The Map endpoints to recipes table maps all covered endpoints in one place.
These are blueprints, not turnkey deployments; lift the projection, schema, and queries you need. See the use cases for ready-made recipe bundles: Accounting & Tax, Portfolio Tracking, Token Analytics, Trading & Charting, NFT Marketplace, Compliance & AML, and Onchain Event Indexing.

​
Get started

Data Feeds is currently in early access.

Try it today

Work directly with the Moralis team to run recipes against your own infrastructure.