> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trustware.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GET /allowance

> Read the ERC-20 allowance an owner has granted to a spender on a given EVM chain. Proxied through Trustware so you do not need a public RPC endpoint.

`GET https://api.trustware.io/api/v1/sdk/rpc/evm/allowance`

Returns the ERC-20 allowance an `ownerAddress` has granted to a `spenderAddress` on a specific EVM chain. Trustware proxies the underlying call so you don't have to manage public RPC endpoints or rate limits per chain.

Use this before broadcasting a route transaction whose source token is an ERC-20. If `allowance` is below `fromAmount`, prompt the user to approve the spender first.

<Note>
  The spender is always a provider contract, never a Trustware contract. When the
  route response includes `route.execution.approvals`, each entry is authoritative
  for one allowance: check against its `spender`, not against
  `route.execution.transaction.to`. Re-quoting can change the selected provider
  and therefore the required allowances, so read them from the latest
  `POST /route` response. See [token approvals](/api-reference/route#token-approvals).
</Note>

## Query parameters

| Parameter | Required | Description |
| - | - | - |
| `chainId` | Yes | EVM chain ID as a string (e.g. `"8453"` for Base, `"1"` for Ethereum). |
| `tokenAddress` | Yes | ERC-20 token contract address. |
| `ownerAddress` | Yes | Wallet address whose allowance you are reading. |
| `spenderAddress` | Yes | The spender to check allowance against. Take it from `route.execution.approvals[].spender` in the latest `POST /route` response, which is authoritative when present. |

## Request

```bash theme={null}
curl -G "https://api.trustware.io/api/v1/sdk/rpc/evm/allowance" \
  -H "X-API-Key: $TW_KEY" \
  --data-urlencode "chainId=8453" \
  --data-urlencode "tokenAddress=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" \
  --data-urlencode "ownerAddress=0xeb212fe20f26243ec4d4df2dd49c8aa9fa75a201" \
  --data-urlencode "spenderAddress=0xce16F69375520ab01377ce7B88f5BA8C48F8D666"
```

## Response

```json theme={null}
{
  "success": true,
  "data": {
    "chainId": "8453",
    "tokenAddress": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
    "ownerAddress": "0xeb212fe20f26243ec4d4df2dd49c8aa9fa75a201",
    "spenderAddress": "0xce16f69375520ab01377ce7b88f5ba8c48f8d666",
    "allowance": "115792089237316195423570985008687907853269984665640564039457584007913129639935",
    "rpcHost": "base-mainnet.example"
  }
}
```

| Field | Description |
| - | - |
| `success` | `true` if the call resolved against the chain. |
| `data.chainId` | Chain ID the call was made against. |
| `data.tokenAddress` | Lowercased token contract address. |
| `data.ownerAddress` | Lowercased owner address. |
| `data.spenderAddress` | Lowercased spender address. |
| `data.allowance` | Allowance as a string-encoded `uint256` in the token's smallest unit. The value `2^256 - 1` indicates an "unlimited" approval. |
| `data.rpcHost` | The upstream RPC host Trustware used. Useful for debugging. |

## Errors

The endpoint returns `{ "success": false, "error": "...", ... }` for validation failures (invalid address, unsupported chain) or upstream RPC failures. Inspect the HTTP status code alongside the error payload:

* `400`: malformed address, unsupported chain, or missing query parameter.
* `429`: rate limit hit; honor the `Retry-After` header.
* `500` / `502`: upstream RPC failed after retries.

<Note>
  Compare `allowance` to the `amount` on the matching
  `route.execution.approvals` entry, or to your route's `fromAmount` when no
  approvals are returned (both in the token's smallest unit). If the allowance is
  lower, prompt the user to approve the spender before broadcasting.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.