> 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)"
  }
}
```