# Estimate Fee **POST /wallets/{walletId}/payment-fees**

status: stable

Estimate fee for the transaction. The estimate is made by assembling multiple transactions and analyzing the distribution of their fees. The estimated_max is the highest fee observed, and the estimated_min is the fee which is lower than at least 90% of the fees observed. ## Servers - https://localhost:8090/v2: https://localhost:8090/v2 () ## Parameters #### Path parameters - **walletId** (string(hex)) ## Body parameters Content-type: application/json - **payments** (array[object]) A list of target outputs with amounts specified. When creating a new transaction, the wallet software ensures that all user-specified transaction outputs have ada amounts that satisfy the ledger minimum UTxO rule: - If a user-specified transaction output has an ada `amount` that is **zero**, the wallet software will automatically assign a minimal amount of ada to the output so that it satisfies the ledger minimum UTxO rule. - If a user-specified transaction output has an ada `amount` that is **non-zero**, the wallet software will verify that the specified amount is large enough to satisfy the ledger minimum UTxO rule. If the amount is not large enough, the wallet software will return a `utxo_too_small` error, together with a revised ada amount that does satisfy the minimum UTxO rule. - **withdrawal** (string) When provided, instruments the server to automatically withdraw rewards from the source wallet when they are deemed sufficient (i.e. they contribute to the balance for at least as much as they cost). As a consequence, the resulting transaction may or may not have a withdrawal object. Summarizing: withdrawal field | reward balance | result --- | --- | --- `null` | too small | ✓ no withdrawals generated `null` | big enough | ✓ no withdrawals generated `"self"` | too small | ✓ no withdrawals generated `"self"` | big enough | ✓ withdrawal generated - **metadata** (object | null) **⚠️ WARNING ⚠️** _Please note that metadata provided in a transaction will be stored on the blockchain forever. Make sure not to include any sensitive data, in particular personally identifiable information (PII)._ Extra application data attached to the transaction. Cardano allows users and developers to embed their own authenticated metadata when submitting transactions. Metadata can be expressed as a JSON object with some restrictions: 1. All top-level keys must be integers between `0` and `2^64 - 1`. 2. Each metadata value is tagged with its type. 3. Strings must be at most 64 bytes when UTF-8 encoded. 4. Bytestrings are hex-encoded, with a maximum length of 64 bytes. Metadata aren't stored as JSON on the Cardano blockchain but are instead stored using a compact binary encoding (CBOR). The binary encoding of metadata values supports three simple types: * Integers in the range `-(2^64 - 1)` to `2^64 - 1` * Strings (UTF-8 encoded) * Bytestrings And two compound types: * Lists of metadata values * Mappings from metadata values to metadata values It is possible to transform any JSON object into this schema. However, if your application uses floating point values, they will need to be converted somehow, according to your requirements. Likewise for `null` or `bool` values. When reading metadata from chain, be aware that integers may exceed the javascript numeric range, and may need special "bigint" parsing. - **time_to_live** (object) The TTL (time to live) is the time period in which the transaction will be accepted into node mempools. After the TTL has lapsed, the transaction is considered expired. At this point, nodes will give up on broadcasting the transaction, and the wallet will release the funds allocated to the transaction so they can be used for other payments. The TTL should be long enough that the transaction has time to be propagated through the network and confirmed, but short enough so that - in the event of failures - UTxO are returned to the wallet in a timely manner. The TTL value is given in seconds. It will be converted to a slot number internally. If the TTL is not provided for a payment, a reasonable default value will be used. ## Responses ### 415: Unsupported Media Type #### Body Parameters: application/json (object) - **message** (string) May occur when providing an invalid 'Content-Type' header. - **code** (string) ### 406: Not Acceptable #### Body Parameters: application/json (object) - **message** (string) May occur when providing an invalid 'Accept' header. - **code** (string) ### 404: Not Found #### Body Parameters: application/json (object) - **message** (string) May occur when a given walletId does not match with any known wallets (because it has been deleted, or has never existed). - **code** (string) - **info** (object) ### 400: Bad Request #### Body Parameters: application/json (object) - **message** (string) May occur when a request is not well-formed; that is, it fails to parse successfully. This could be the case when some required parameters are missing or, when malformed values are provided. - **code** (string) ### 403: Forbidden #### Body Parameters: application/json (object) - **message** (string) May occur when trying to perform an operation not supported by this type of wallet. - **code** (string) ### 202: Accepted #### Body Parameters: application/json (object) - **estimated_min** (object) Coins, in Lovelace. Only relates to 'Ada'. Refer to `assets` for multi-assets wallets instead. - **estimated_max** (object) Coins, in Lovelace. Only relates to 'Ada'. Refer to `assets` for multi-assets wallets instead. - **minimum_coins** (array[object]) A list of minimum coin values that each output in a payment must satisfy. The values themselves depends on two things: - (a) Some updatable protocol parameters fixed by the network. - (b) The nature of the outputs (i.e. the kind of assets it includes). The list is a direct 1:1 mapping of the requested outputs. Said differently, it has the **same number of items** and **items are ordered in the same way** as **requested outputs** are ordered. In the case where there's no explicitly requested outputs (e.g. when calculating fee for delegation), this list is empty. For example, an output containing only `Ada` may require to be of at least `1 Ada`. An output containing only an hypothetical `AppleCoin` may require to also carry a minimum of `1.2 Ada`. Note that no matter what, a minimum coin value is always given in Lovelace / Ada. > ℹ️ This mechanism is used by the protocol to protect against flooding of the network with worthless assets. By requiring a minimum coin value to every UTxO, they are given an intrinsic value indexed itself on the value of Ada. - **deposit** (object) Coins, in Lovelace. Only relates to 'Ada'. Refer to `assets` for multi-assets wallets instead. [Powered by Bump.sh](https://bump.sh)