Our Support Status for Bitget

This page introduces the trade types that can be obtained via Bitget file and API.

*1 The funding fees for futures trading have been successfully confirmed to reflect without any issues in both files and APIs.

*2 In the API distribution, we confirmed that from May 30, 2024 (specific time unknown/Japan Standard Time), interest income from flexible savings is distributed as "FINANCIAL_BATCH_FUND_INVESTMENT_USER_IN" instead of "Financial." Therefore, we have decided to reflect "FINANCIAL_BATCH_FUND_INVESTMENT_USER_IN" distributed in the updated API on June 14, 2024, as "Bonus."

We have received information that, in the files, interest income from flexible savings has been labeled as "365" starting from May 30, 2024 (specific time unknown) in Japan time. Therefore, we have decided to reflect "365" on the file on Oct 31, 2024, as "Bonus."

*3 However, the system does not support loan history (where the amount is positive under 'Borrow') and loan repayment history (where the amount is negative under 'Borrow'). Therefore, please upload the history manually using a custom file.

The reason for this is that the repayment history (where the amount is negative under 'Borrow') already includes the interest paid as part of the repayment amount. As a result, it is impossible for a third party to determine how much of the repayment was interest from the file's history, which is why we cannot currently automate this process.

*4 Regarding the copy trade history, both API and file support "Copy Trade profit" and "Copy Trade expense" for spot trading.
If there are any other copy trade histories for spot trading that are not reflected, please contact support.
Additionally, as we are currently collecting samples for futures trade histories, they are not supported at this time.

【Files】

• "Financial"・・・The history labeled as "Financial" in the file (distributed as "Financial" via API) has been confirmed to be used for multiple different transaction types on the Bitget side. Therefore, from the term "Financial," third parties cannot determine what kind of transaction the customer has conducted, and we handle it as "To confirm transactions" Consequently, customers need to select the correct transaction type on the screen themselves.
• Numbers displayed as transaction type・・・Due to lack of sufficient details in the file, cryptact handle those transactions as "To confirm transactions" .
  When the file is uploaded, a transaction type called "to confirm" is displayed

•  "bonus_issue," "bonus_expired," "bonus_recycle"・・・Starting Thursday, September 12, 2024, "bonus_issue" will be treated as Bonus/BONUS and "bonus_expired" as Loss/LOSS. "bonus_recycle" will continue to be treated as Loss/LOSS.

  Previously, "bonus_issue" was not reflected in the transaction list as it was considered a margin bonus that couldn’t be used until a loss occurred. Similarly, unused "bonus_expired" bonuses were not reflected. However, to avoid showing larger losses than actual, we’ve now updated how these transactions are processed.

• "Received from delivery," "Deducted for delivery"・・・We understand that 'Received from delivery' and 'Deducted for delivery' are part of pre-market history, but since the transaction dates do not match, the system cannot process them as the same pair. Therefore, the uploaded file will not be reflected in the system. Please upload the history separately using a custom file.

【API】

• The history distributed as "Financial" via API has been confirmed to be used for multiple different transaction types on the Bitget side. Therefore, from the term "Financial," third parties cannot determine what kind of transaction the customer has conducted, and we handle it as "To confirm transactions" Consequently, customers need to select the correct transaction type on the screen themselves. Here is the method to handle transactions that require identification.