Documentation Index
Fetch the complete documentation index at: https://docs.moralis.com/llms.txt
Use this file to discover all available pages before exploring further.
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. 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.
How a recipe works
Every recipe is the same three-stage pipeline:- 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).
- Transform — a projection that expands the arrays you care about into one row per event and shapes them into the endpoint’s schema.
- Destination — the rows land in your database, indexed for the access pattern the endpoint serves (by wallet, by token, by pair, …).
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-
topic0grouping 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
uint256amounts as text, USD as wide decimals.
Destinations
Recipes support three destinations. ClickHouse is the first-class path — it’s the only one that handles live, reorg-safe ingestion:| Destination | Best for | Realtime / reorg-safe |
|---|---|---|
| ClickHouse | Production, large windows, live tailing | ✅ Yes — corrects chain reorganizations automatically |
| Postgres | Historical backfill, analytics, smaller windows | Backfill-first |
| MySQL | Historical backfill, existing MySQL stacks | Backfill-first |
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
| Mode | What it does | Default for |
|---|---|---|
historical | One-shot backfill of a block window | Postgres / MySQL |
realtime | Live tail from the chain head | — |
hybrid | Backfill, then a seamless handoff to realtime | ClickHouse |
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 kind of data they serve. ⭐ marks the most popular endpoints.| Domain | Recipe | Answers |
|---|---|---|
| Wallet | Wallet History ⭐ | Every event a wallet was involved in |
| Token Balances by Wallet ⭐ | Every token a wallet holds, with balance | |
| Native Balances | Native-asset balance per wallet | |
| NFTs by Wallet ⭐ | Every NFT a wallet holds | |
| Token Approvals | Current allowances a wallet has granted | |
| Token | Token Prices ⭐ | USD/native mark history for a token |
| Token Holders ⭐ | All non-zero holders of a token | |
| Token Balances by Token | Holder balances, keyed by token | |
| Token Transfers | Every transfer of a token | |
| Token Stats | Per-token transfer counters | |
| Token Metadata | Name, symbol, decimals, supply | |
| Swaps & Markets | Swaps by Wallet ⭐ | Every DEX trade made by a wallet |
| Swaps by Token ⭐ | Every DEX trade touching a token | |
| Swaps by Pair | Every DEX trade on a pool/pair | |
| Pair OHLCV | Candles per pool | |
| Pair Reserves | Current reserves per pool | |
| NFT | NFT Trades | Marketplace trades per collection / token / wallet |
| NFT Transfers | Every NFT movement | |
| NFT Owners by Contract | Current owners of a collection | |
| NFT Collection Metadata | Collection-level metadata | |
| Logs & Events | Contract Logs | Every raw event log emitted by a contract |
| Logs by Event Signature | One event signature (topic0) across all contracts |
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.Request Early Access
Work directly with the Moralis team to run recipes against your own infrastructure.