Skip to main content
The Funding (Beta) API replaces the legacy /0/private funding endpoints with stable IDs, reusable address scopes, and fee pinning. Relative to v0, the main gains are:
  • Stable IDs for methods, networks, and addresses. Integrations are not tied to fragile display-name strings
  • Reusable withdrawal addresses. Save once at network or network-group scope and use across methods
  • Fee pinning. Lock a quoted fee rate with a fee token so automated withdrawals are insulated from fee changes between quote and submit
  • Simpler Query Funds permissioning for read-only endpoints. Monitoring keys no longer need compound Withdraw or Deposit permissions (a Query Funds-only key can therefore access more via these endpoints than it could on the legacy API, including withdrawal addresses and history). See New Funding Endpoints - Permission Changes From Legacy.
This guide covers:
  1. Adding a withdrawal address
  2. Creating a withdrawal
  3. Claiming a deposit address and depositing crypto
Authentication uses the same API key and secret as the rest of the Kraken REST API. For key setup, see Spot REST Authentication. Funding requests sign each call and send api-key, api-sign, and api-nonce headers as shown in the helper below (the signed path includes the query string). Schemas are in the Funding API reference.

Prerequisites

  • A Kraken account with an API key that includes the funding permissions you need. See Permission Changes From Legacy for how those permissions differ from the legacy endpoints, and Withdrawal addresses API permission Risks for the risks of Add withdrawal addresses.
  • Your API secret for request signing
  • For withdrawals: a funded balance and a verified destination address

Shared Python helper

The examples below call this helper. Nested query objects are encoded as asset[class]=… style parameters, matching what these Funding API endpoints expect.

Section 1: Adding a withdrawal address

In the new Funding API, each saved withdrawal address is stored against exactly one scope: a funding method, a network, or a network group. The scope you choose controls which withdrawals can use that address later.

How networks and methods group together

Funding methods sit under networks, and related networks sit under network groups:
Broader scope means more reuse. Saving once at the EVM network-group level means you do not need a separate saved address for every EVM method underneath it. Saving at the Ethereum network level reuses the address across assets on Ethereum. Saving at the method level limits the address to that one route.
Addresses saved against a network or network_group scope are fully usable through the API today, but they do not yet appear in the Kraken website withdrawal address book. Frontend support for these broader scopes is planned soon.Managing fiat withdrawal addresses through the Funding API is not available at this time. The address book endpoints support crypto withdrawal addresses only. Fiat withdrawals can still be submitted with Create Funding Withdrawal using fiat addresses added via the Kraken UI.

Which addresses are returned when you list

Listing expands upward only. The filter you pass decides how far up the tree the response looks:
  • List by method returns addresses saved on that method, its network, and its network group.
  • List by network returns addresses saved on that network and its network group, not method-only addresses under the network.
  • List by network group returns only group-scoped addresses.
When you withdraw with a given method, you can use any address returned by listing with that method’s method_id: group-, network-, or method-scoped. That list is the complete set of destinations valid for the withdrawal.

Endpoints in this flow

Use these endpoints to discover IDs, create an address, and confirm what is usable:

Saving a withdrawal address

The following example saves a reusable Ethereum address for withdrawals.

Step 1: List funding networks

discover network_id and network_group_id values:
Response:

Step 2: List funding methods

Select the withdraw method for your asset and note its network. Filter by asset using a nested asset object. In the query string that becomes asset[class]=currency&asset[name]=USDC:
Response:
From here:
  • method_id = 67b765fd-4efd-42dc-8ce7-63352971d566
  • network_id = d9d375da-44b7-4be1-8a00-8b281acfe366 (Ethereum)
  • network_group_id = f95acdb7-48fb-4441-b5b4-843d3bf60e61 (EVM)

Step 3: Create funding address

Save the address at network scope so any funding method on Ethereum can use it:
Response:
Addresses created through this endpoint are verified automatically and do not require email verification. That makes API-managed destinations immediately usable for withdrawals. Review the risks of this permission in Withdrawal addresses API permission. Use scope.method_id or scope.network_group_id instead when you want narrower or broader reuse. On blockchains that allow a tag or memo, you can include an optional tag or memo under address_details.crypto. Either field is accepted.
If you save an address with tag but the method or network uses memo, List Funding Addresses returns the value as memo. The same applies in reverse.

Step 4: List funding addresses

List by method to see every address usable for USDC - Ethereum:
Response. Notice the three scopes in one method-scoped list:
Listing the same book by network omits method-only addresses:
Listing by network group returns only group-scoped addresses:
Any of the addresses returned by the method-scoped list can be passed as address_id when you create a withdrawal for that method.

Section 2: Creating a withdrawal

Workflow

  1. List funding methods: choose the withdraw method_id.
  2. Calculate funding fees: quote the fee and receive a withdrawal_fee_token.
  3. Create funding withdrawal: submit with address_id and the fee token.

Step 1: List funding methods

Reuse the methods call from Section 1. In this example we withdraw 5 USDC on Arbitrum One (USDC - Arbitrum One):
  • method_id: d4ec4d52-b159-428e-ba64-f45455a978a1
  • address_id: ABR6SXP-SF6CY-VJMONY (EVM network-group scoped address, valid for Arbitrum)

Step 2: Calculate funding fees

Response (token truncated):
fee_included=true means the amount you pass is the total debit from your balance. The withdrawal_fee_token is an unique quote token returned with the fee calculation. It locks in the quoted fee rate (the base fee and any percentage component) so a later withdrawal can charge that rate instead of whatever the live fee happens to be at submit time. The token is valid for 5 minutes from when it was issued, and you can reuse the same token on multiple withdrawals during that window. After it expires, request a new quote. When you withdraw with a token, use the same fee_included setting you used for the quote. If you withdraw the same amount you quoted, the fee matches the quote exactly. If the method charges a percentage and you withdraw a different amount, that percentage is reapplied to the new amount while still using the locked-in rate.

Step 3: Create funding withdrawal

Submit the fee token under fee.quoted_fee.token:
Response:
Notes:
  • scope selects the withdraw method. You can pass network_id instead only when that network has exactly one available method for the asset; otherwise the request is ambiguous.
  • The destination address_id may be method-, network-, or network-group-scoped, as long as it is compatible with the method you selected.
  • Instead of a fee token, you can accept the current fee and optionally set a maximum:
  • Optional expected_address lets you confirm the on-chain destination still matches the saved address before the withdrawal proceeds.

Section 3: Depositing funds

Deposit addresses belong to a funding method: one way to move one asset on one network, for example depositing USDC on Ethereum. You always claim and list with a method_id. You do not choose a network or network-group scope the way you do for withdrawal addresses.

Workflow

  1. List funding methods: choose a deposit method_id.
  2. List claimed deposit addresses: reuse an existing address if one is returned.
  3. Claim funding deposit address: only when you need another address.
Claiming can reserve a new address, so list first and only claim when you need another one. Some methods share an on-chain address with another method. You can still list and claim with the method you want to deposit to. See Shared deposit addresses if you need that model.

Step 1: List funding methods

Response:
address_generation tells you whether you can create more unused addresses for this method (unlimited, limited plus limit, or unsupported). If shares_addresses_with_method_id is present, this method reuses another method’s addresses. You can ignore that field for the walkthrough below and still list or claim with this method_id.

Step 2: List claimed deposit addresses

This is the call to make when a user selects a deposit method and you need the address (and any tag or memo) to display. Pass the method as scope.method_id.
Response:
If tag or memo is present, include it with the address. Deposits sent without a required tag or memo may not be credited. If the list is empty, claim an address in Step 3. Deposit claimed-address listing is separate from the withdrawal address book in Section 1.

Step 3: Claim funding deposit address

Claim with the method_id you want to deposit to. That does not have to be the method the address is stored against. If the method shares addresses, Kraken returns the shared address.
Response:
Where address_generation is limited (typically limit: 5), you may hold up to five unused claimed addresses for that method at a time. If you are already at the limit, claim returns TooManyDepositAddresses. List existing addresses instead. Once one of those addresses has received a deposit, you can claim another; the oldest unused address then begins expiring and is removed after 7 days.

Shared deposit addresses

On many networks, token deposit methods use the same on-chain address as the network’s native asset. Kraken stores that address against the native method. The token methods reuse it. Ethereum looks like this: The same pattern applies on Tron (TRC-20s stored against TRX) and Solana (SPLs stored against SOL). List Funding Methods tells you this with deposit.shares_addresses_with_method_id. The field is omitted when a method has its own addresses. You still list and claim with the method the user selected. For USDC on Ethereum, pass the USDC method_id. Kraken returns the shared ETH address. You do not look up or claim against ETH on Ethereum first. The same is true for a TRC-20 on Tron or an SPL on Solana.
Not all networks that have an EVM deposit address share addresses. Methods on the same network can share (ERC-20s with ETH on Ethereum, TRC-20s with TRX on Tron, SPLs with SOL on Solana). Methods in the same network group do not always share. Trust shares_addresses_with_method_id rather than assuming two methods share because they look related.

The same address, two method_id values

method_id on a claimed address is not always the method the address is stored against. It depends on the list filter. Listed for USDC (scope.method_id = USDC on Ethereum), as in Step 2. Use this when you are showing the user where to send USDC:
Listed with no method filter. method_id is ETH on Ethereum, because that is where the address is stored:
The same split happens on other networks. A TRC-20 listed by its own method_id reports that token method; listed with no method filter it reports TRX on Tron. An SPL listed by its own method reports the SPL; unscoped it reports SOL on Solana. If you list every claimed address and then keep rows whose method_id is USDC, you will miss this address. Put USDC in scope.method_id on the request instead.