Bitget sub-account fees: check the inherited rate before an API order

Start with the account that sends the order

Bitget's creation guide describes virtual, general and custodial trading sub-accounts. A virtual sub-account is accessed by switching from the main account; a general sub-account has separate login credentials. The guide also allows API-key creation for sub-accounts with permissions that can be customized. These distinctions matter when a trading program and a browser window show different account contexts. Bitget's sub-account guide describes those arrangements.

Before comparing a program's estimate with a displayed rate, write down the sub-account identifier associated with the order. Then identify the market and the account mode used by that strategy. Keep those details beside the fee observation. A screenshot of a parent account's status is a useful starting record, but it leaves the identity of the order-sending account unanswered.

The NexuAlpha Bitget profile is a place to begin a broader venue comparison. For an existing strategy, the immediate cost question is narrower: which account's rate did the program use? Resolve that before changing any order settings or adding funds to chase a different tier.

What the inheritance rule establishes

In its definitions, Bitget says that 30-day trading volume includes main and sub-accounts and is calculated daily at midnight UTC+8, which is 00:00 SGT. It states that a sub-account inherits the main account's fee rates when created. These are published program rules, rather than a measurement of the account you are viewing.

Read the timing language literally. “When created” tells you the starting relationship. If a parent account's status has changed since a strategy was configured, check the fee response again instead of treating the initial setup record as permanent. The public document does not tell us an individual account's current assigned rate or whether a particular order was charged correctly.

The same document distinguishes professional account treatment from the ordinary VIP program. It describes API trading ratio as API spot and futures volume divided by total spot and futures volume. Its upgrade table uses an API trading ratio above 20% alongside volume requirements. A user who merely enables an API key has not, by that action alone, demonstrated those conditions.

For a household-sized strategy, this distinction can prevent a bad comparison. Do not select a rate from a professional table because the order arrives through software. First identify whether that program actually applies to the account. The page's qualification rules and the account's assigned treatment must be considered together.

Ask for the product and symbol you actually trade

The official unified-account documentation describes an account-fee query with two required inputs: symbol and category. Its listed categories include spot, margin, USDT futures, coin-margined futures and USDC futures. A rate obtained for one product is not evidence for a different product. Match both inputs to the order you are investigating.

The response contains separate rate fields for the two execution classifications. For cost reconciliation, use the classification recorded for the fill. This article does not assume that every API order falls into the same category or that a strategy's label describes its eventual execution. The relevant evidence is the rate returned for that market and the account's own transaction record.

SponsoredBitget

Partner rebate share60%Up to

Check regional eligibility and account terms

→Enter the code when you sign up: nexu888

Sign up on Bitget →Codenexu888Copied

The documentation says account-management read permission is required. An existing integration can use the documented read function within its authorized setup; the public example is not a reason to publish credentials or grant a new program trading access. Someone checking costs manually can record the account's displayed fee information and compare it with their completed fills.

Keep authentication material out of the worksheet. The fields needed to discuss a discrepancy are the account context, market, product, observation time, quoted rate and fill record. None requires putting a secret into a screenshot or support message.

Decimal rates: a worked cost check

The documentation's conversion example is precise: 0.0002 represents 0.02%. Using that example rate, our calculation for a hypothetical fill is:

10,000 USDT filled value × 0.0002 = 2 USDT trading fee.

The 10,000 USDT value is an illustration, and the decimal is the documentation's example. It is not a current quote for every Bitget user. If the account returns another rate, replace the example with that response before making a trading budget.

Suppose, purely for arithmetic, that the entry fills for 10,000 USDT and the later exit fills for 10,200 USDT, both at the example decimal rate. The entry fee is 2 USDT. The exit fee is 10,200 × 0.0002 = 2.04 USDT. Their sum is 4.04 USDT. Charging the initial amount twice would miss the different exit value.

For a partially filled order, begin with the value that actually filled. In a hypothetical 10,000 USDT request with only 4,000 USDT executed, the same illustrative decimal produces 0.80 USDT for that executed portion. This calculation does not estimate the cost of an unfilled remainder or promise that the rest will execute at the same price.

A decimal-unit mistake can overwhelm the comparison. Multiplying 10,000 by 0.02 gives 200, while multiplying it by 0.0002 gives 2. The first input treats a percentage number as a decimal rate. Preserve the returned units in your notes so a spreadsheet does not silently substitute one for the other.

Keep other cash flows outside that calculation

The worked example measures a trading fee on a filled value. If you are evaluating a futures strategy, keep any funding payments in their own column. For transfers, keep any withdrawal charge in another column. Adding an unrelated payment to the trading-fee figure makes it harder to see which input needs correction.

This is a reconciliation method, not a claim about the current funding rate, withdrawal charge or transfer availability of a specific account. Record those figures only from the relevant account records. The public pages opened for this article establish the fee-query format and sub-account rules; they do not supply those personal transactions.

The distinction also helps with performance reporting. In a hypothetical strategy statement, record trading profit or loss, trading fees and other account movements separately before calculating the net result. A transfer from the parent account increases the sub-account balance without proving that the strategy earned that amount. Follow the transaction entries rather than treating a balance change as a fee adjustment.

What this means for you

On Bitget, first compare the account identified in the strategy with the sub-account whose costs you are checking. Then use the product-specific rate and the completed fill record to calculate the expected trading charge.

• Check the sub-account identity, symbol, product and observation time before comparing rates.
• Compare the filled value and fee units with the corresponding transaction record; review any mismatch before increasing the strategy's size.

Use the Bitget account and fee profile for the venue overview, while keeping the account-specific worksheet beside your own fills. There is no rebate percentage or sign-up reward in the calculation above. It answers what the documented rate means for a trade, using an explicitly hypothetical value.

When the estimate and the charged fee disagree

Work through the mismatch in an order that preserves the evidence. Begin with the account identity, then the market category, then the rate units, and finally the filled amount and recorded charge. Keep the original observations; overwriting a rate in a spreadsheet can erase the reason the estimate looked different.

If the order has several fills, reconcile each recorded portion before comparing the total. A single order value in a strategy configuration may describe an intended size, while the transaction history describes what actually happened. Use the latter for the arithmetic and retain the former as a planning input.

When an account status changes, record the time of the fee observation as well as the fill time. That gives a support inquiry a concrete question: why does this completed fill differ from the rate recorded for this account and product? Avoid asking support to explain a generic rate copied from a different program's table.

Quick answers

Does a sub-account automatically get a cheaper fee?

Bitget's published rule says a new sub-account inherits the main account's rates. The creation step alone does not establish a discount. Confirm the account's applicable treatment and product-specific rate.

Is the documented 0.0002 value a universal live rate?

It is an example used to explain decimal units. The documentation equates it with 0.02%. An individual account's returned rate must be checked separately.

Does enabling an API key establish PRO eligibility?

The PRO page lists qualification and upgrade conditions, including API-volume criteria for the upgrade tracks. The ability to create an API key in a sub-account is a separate feature described in the creation guide.

What should I retain for a fee query?

Keep the sub-account identifier, product, symbol, rate observation time, filled value and transaction charge. That gives the comparison a specific account and trade without exposing authentication material.