# How eth_getLogs works?

By [WatchData](https://paragraph.com/@gr0wth) · 2022-03-03

---

![](https://storage.googleapis.com/papyrus_images/54da6e11a24811240143c2d959da04bc1289320c6cc46a955fcb16a642367f8a.png)

Hello everyone 🖖
-----------------

We continue our series of articles about our API and today we want to take a look at the often used **eth\_getLogs**.

eth\_getLogs has a lot of useful options that developers often don't know about. Let's give you an example of how to work with this query.

For more information about the request/response specifications for `eth_getLogs`, see our [documentation](https://docs.watchdata.io/blockchain-apis/ethereum-api/eth_getlogs-new)

What are Logs?
--------------

Logs and events are used synonymously - smart contracts generate logs by triggering events, so logs provide insight into the events that occur within a smart contract. Logs can be found on transaction recipes.

Query eth\_getLogs
------------------

When you make a request to `eth_getLogs`, all parameters are OPTIONAL, that is, you don't need to specify `fromBlock`, `toBlock`, `address`, `topics` or `blockHash`

Let’s look at an example of a request. Take the USDT address and limit the search parameters from 10,000,000 block to 10,000,001 block. Let's add a topic on event transfers. We'll describe it in more detail below

    {
        "id": 1,
        "method": "eth_getLogs",
        "jsonrpc": "2.0",
        "params": [
            {
        "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7", 
        "fromBlock": 10000000, 
        "toBlock": 10000001,
        "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
            }
        ]
    }
    

In our `params`here we have specified the`address`, `fromBlock`and `toBlock`

> **⚠️ We use** `fromBlock` **and** `toBlock` **in our params. It is important to understand that you can use either** `fromBlock`**and** `toBlock`**or** `blockHash`**, not both.**

The `fromBlock` and `toBlock` parameters specify the start and end block numbers to limit the search. The `address` field represents the address of the contract that creates the log.

`Topics`is an ordered array of data. Notice how the first item in the `topics`  field above matches the _event_ signature of our `Transfer(address,address,uint256)`.

This means that we specifically request the Transfer event. So I will get all transfers in USDT from 10,000,000 block to 10,000,001 block.

Now that we have a better understanding of how to make queries, let's look at the answer.

Response
--------

You will get a list of logs in a given range (You will get a response with much more data than the following):

    {
        "id": 1,
        "jsonrpc": "2.0",
        "result": [
            {
                "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
                "blockHash": "0xaa20f7bde5be60603f11a45fc4923aab7552be775403fc00c2e6b805e6297dbe",
                "blockNumber": "0x989680",
                "data": "0x00000000000000000000000000000000000000000000000000000000121eac00",
                "logIndex": "0x3",
                "topics": [
                    "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                    "0x00000000000000000000000039bb7d39a395e0ce36875244ad48bcaec54faf03",
                    "0x0000000000000000000000009354de9e63674f3e44303b8cc3853d7f10f97d06"
                ],
                "transactionHash": "0x80e195cabafd0358a35cec5fadc9b304734ac1f0ed6edf607d170dab13f5e069",
                "transactionIndex": "0x7",
                "removed": false
            }
    ..............................
    }
    

The interesting fields to watch out for are `data` - which is an unrestricted field for encoding hexadecimal data related to a specific event. By default, if the information is not indexed in the other topics field, it is automatically placed in the data field. This requires more work to analyze the individual hex string information rather than their indexed topics.

And `topics` - can contain up to 4 topics. The first topic is mandatory and will always contain hash keccak 256 event signature. As you may see the example above shows a Transfer event between address 0x39bb7d39a395e0ce36875244ad48bcaec54faf03 and 0x 9354de9e63674f3e44303b8cc3853d7f10f97d06(the second and third topics).

We can check this data on [etherscan](https://etherscan.io/)

![](https://storage.googleapis.com/papyrus_images/9c837400f6bba71dbb28d74f3091196d5fa175bebbe31f89aca68d85ee48ca68.png)

Now you know a bit more about the eth\_getLogs.

* * *

But if you want to receive and process transfers and not spend a lot of time processing logs, you can use our [**watch\_getTransfers**](https://docs.watchdata.io/structured-data/transfers) method.

We will tell you about it in one of our next articles, but for now you can read about it in the [documentation](https://docs.watchdata.io/introduction/welcome-to-watchdata-docs).

* * *

1.  Join to [our Discord server](https://discord.com/invite/TZRJbZ6bdn)
    
2.  Please leave your feedback in the #feedback channel. If you have any problems or you think that some functionality is not working correctly, we are waiting for your feedback.
    
3.  Want a new feature or you miss some functionality, tell us about it in the #general channel. We are always open to your ideas!
    

#### HELPFUL LINKS

*   [WatchData main](https://www.watchdata.io/)
    
*   [Raw Data](https://www.watchdata.io/raw-data)
    
*   [Structured data](https://www.watchdata.io/structured-data)
    
*   [Metrics for analysis](https://watchdata.notion.site/Metrics-for-analysis-98dea0a697764bc6ae51643828449dc9)
    
*   [For Miners](https://watchdata.notion.site/For-Miners-70367c9705ae482c90674d070eedea61)
    
*   [WatchData Twitter](https://twitter.com/Watchdata_web3)
    
*   [WatchData Discord](https://discord.com/invite/TZRJbZ6bdn)
    
*   [WatchData Docs](https://docs.watchdata.io/introduction/welcome-to-watchdata-docs)

---

*Originally published on [WatchData](https://paragraph.com/@gr0wth/how-eth-getlogs-works)*