> For the complete documentation index, see [llms.txt](https://docs.shyft.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.shyft.to/solana/get-transactions-for-address.md).

# getTransactionsForAddress

Fetching complete transaction data for a Solana address normally takes <mark style="color:yellow;">two steps</mark> : &#x20;

* **getSignaturesForAddress** to get signatures,&#x20;
* then a **getTransaction** call for each one \
  On top of that you have to take care of manual pagination, status filtering, and token account lookups on the client side.

<mark style="color:$primary;">**getTransactionsForAddress**</mark>**&#x20;**<mark style="color:yellow;">**collapses all of that into a single request**</mark>**, with filtering, pagination, and token account lookups handled server-side.**

{% hint style="success" %}

#### <mark style="color:$primary;">getTransactionForAddress</mark> is a custom RPC call provided by Shyft. It is not part of the standard Solana RPC interface. Currently 2 epochs of data is available.

{% endhint %}

A single call can return either signature-level information or full transaction payloads, apply slot/time/status/accounts filters before results are returned. Use pagination cursor to easily traverse historical data in either ascending or descending order.

### How It Compares to Standard Solana Methods

| Capability                   | getSignaturesForAddress + getTransaction  | getTransactionsForAddress    |
| ---------------------------- | ----------------------------------------- | ---------------------------- |
| Address history lookup       | 1 + N requests                            | 1 request                    |
| Pagination cursor            | Signature (`before`/`until`)              | Token (`paginationToken`)    |
| Server-side status filter    | ❌                                         | ✅ (`status`)                 |
| Server-side slot/time filter | ❌                                         | ✅ (`slot`, `blockTime`)      |
| Token-account fan-out        | Manual (`getTokenAccountsByOwner` + loop) | ✅ (`tokenAccounts`)          |
| Full transaction payload     | Separate `getTransaction` call per sig    | `transactionDetails: "full"` |

### Example Request

Let's look at a basic <mark style="color:$primary;">getTransactionsForAddress</mark> call to understand different options it provides.

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTransactionsForAddress",
    "params": [
        "pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA",
        {
            "transactionDetails": "signatures", 
            "sortOrder": "asc",
            "limit": 1000,
            "paginationToken": null,
            "commitment": "confirmed"
            "filters": {
                "slot": {
                    "gte": 425211949 //Any slot number you want
                },
                "status": "any",
                "tokenAccounts": "none"
            }
        }
    ]
}
```

{% endcode %}
{% endtab %}

{% tab title="Response" %}
{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "data": [
            {
                "signature": "4LBedoHUMeh1sDr3EqKiYcyGLT4dQQgLLEqqz76k5DSVzCtyMaXHmKGt85kEjXMkQYoiXUKnMBFpn78ziWtfzzcm",
                "slot": 425756281,
                "transactionIndex": 999,
                "err": null,
                "memo": null,
                "blockTime": 1781178051,
                "confirmationStatus": "finalized"
            },
            {
                "signature": "X6DrkpMF9pQXQJqwGRdQwz7qMJSanR22oRw8mg1DP8ukihj4pk9NS1ijpEgPCnxopCcnhXw2vrdmAxRBKzTjWp4",
                "slot": 425756281,
                "transactionIndex": 992,
                "err": null,
                "memo": null,
                "blockTime": 1781178051,
                "confirmationStatus": "finalized"
            },
            //response shortened for visibility
        ],
        "paginationToken": "425756281:979"
    }
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

Understand what each parameter in the request stands for:

<table><thead><tr><th width="114">Option</th><th width="116">Type</th><th width="128">Default</th><th>Description</th></tr></thead><tbody><tr><td>transactionDetails</td><td>signatures | full</td><td>signatures</td><td>Controls response payload. </td></tr><tr><td>sortOrder</td><td>asc | desc</td><td>desc</td><td>Sort direction by slot and transaction position within the block.</td></tr><tr><td>limit</td><td>number</td><td>1000 (signatures) / 100 (full)</td><td>Maximum number of results per page. Hard cap is 1000 for signatures and 100 for full. Exceeding the cap returns a <code>-32602</code> error — it does not silently clamp.</td></tr><tr><td>paginationToken</td><td>string</td><td>null</td><td>Cursor returned by a previous response. Pass this value to fetch the next page. Cursors are opaque — do not construct or modify them.</td></tr><tr><td>commitment</td><td>confirmed | finalized</td><td>finalized</td><td>Commitment level for the query. Matches the semantics of <code>getSignaturesForAddress</code>.</td></tr><tr><td>minContextSlot</td><td>number</td><td>—</td><td>If provided, the node returns an error if it hasn't yet processed up to this slot. Use this when you've just sent a transaction and want to guarantee the node you're querying has advanced past that slot before returning results — otherwise you might query a slightly behind node and miss the transaction you just submitted.</td></tr><tr><td>encoding</td><td>json | jsonParsed | base58 | base64</td><td><code>json</code></td><td>Encoding for the transaction payload. Only relevant when <code>transactionDetails</code> is <code>full</code>. Matches <code>getTransaction</code> encoding behavior.</td></tr><tr><td>maxSupportedTransactionVersion</td><td>number</td><td>—</td><td>Maximum transaction version to return in the response. Requests without this field return an error if any result is a versioned transaction. Set to <code>0</code> to support all current transaction versions. Only relevant when <code>transactionDetails</code> is <code>full</code>.</td></tr><tr><td>filters</td><td>object</td><td>—</td><td>Optional filters applied server-side before results are returned. See below.</td></tr></tbody></table>

***

### Limits and error behavior

The `limit` defaults differ because the payload sizes differ significantly, a response of 1000 signature objects is still small, while 100 full transaction objects can be several megabytes depending on instruction data. Exceeding them returns an error immediately; the server does not silently clamp and return a partial result.

* "transactionDetails": "full", limit: 100
* "transactionDetails": "signatures", limit: 1000

Exceeding these limits will result in the below error:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "limit too large (max 100/1000)"
  }
}
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.shyft.to/solana/get-transactions-for-address.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.