Repay MarginX Debt

Time	Status	User Agent
Retrieving recent requests…

Submits a repayment against one MarginX debt. The payment first covers outstanding interest and then reduces principal. Select the actual paying DMA account or RapidX Portfolio exchange account in the same margin group as the debt.

Rate limit: 10 requests per minute per API key.

LTP covers any transaction fees incurred during borrowing and repayment. You do not pay these fees. Borrowing interest is charged separately under the applicable terms.

API key access

Requires a signed request with TRANSFER permission. See Authentication.

API key type	Can call	Scope
Main User Level API key (also the Main Portfolio key)	Yes	Repay its debts using an eligible member account in the same group.
Sub-user Level API key	No	Not supported.
Dedicated Sub Portfolio Level API key	No	Not supported, even if it holds the debt or repayment funds.
Exchange-native API key	No	Use an LTP Main User Level API key.

READ alone does not authorize repayment. Repayment uses TRANSFER, not a separate lending-write permission.

Before repaying

Query Get Outstanding Debts for the debtId, currency, outstanding principal and interest.
Choose the same-group DMA wallet or RapidX Portfolio exchange account that will actually provide the funds. It can differ from the member carrying the debt. An LTP Funding account is not a supported source; a DMA exchange wallet named FUNDING, such as Bitget's Funding wallet, is a different account type.
Check currency precision, minimum repayment quantity and source transferability. An account's generic available value is not a universal transferable balance. For RapidX, see Get Portfolio Assets Details and maxTransferable; DMA accounts depend on their exchange-native transfer rules. The server performs the final funds and route checks.
Submit once and track every returned requestId through Get Borrowing and Repayment Orders. Recheck outstanding debt to confirm the reduction.

JSON body parameters

Name	Type	Required	Description
`clientOrderId`	string	No	Customer-supplied identifier for the repayment request. When supplied, exactly 18 ASCII letters or digits; case is preserved. Both resulting records share this value if repayment splits.
`debtId`	string	Yes	Debt identifier from the outstanding-debt endpoint, not a borrowing `requestId`, group ID or member ID.
`amount`	string	Yes	Positive total repayment quantity in the debt's currency. Includes both interest and principal; it is not a principal-only instruction. Must satisfy applicable precision and minimum requirements.
`fromPrimeType`	string	Yes	`dma` or `rapidx`.
`fromId`	string	Yes	DMA account ID or RapidX Portfolio ID of the actual payer.
`fromAccountType`	string	Yes	Paying DMA wallet type, or the specific RapidX exchange. See Account Types.

Do not send groupId, currency, toId or a system requestId: the debt determines its group, currency and debt-carrying member. Enum input is case-insensitive; IDs and clientOrderId are preserved.

Amount allocation

Repayment is interest first, then principal. If a debt has principal 65 and interest 6.8, submitting 41 repays 6.8 interest and 34.2 principal, leaving principal 30.8 and interest 0.

A partial repayment reduces the existing debt. When borrowing requests have accumulated into the same debt, repayment does not target a selected original borrowing order. Account for existing interest when calculating how much principal a repayment will remove.

The contract rejects an amount exceeding the current repayable debt instead of silently reducing it. Other in-progress repayments may occupy part of that amount.

Response fields

Field	Type	Description
`code`	integer	`200` means the repayment request was accepted, not that funds were deducted or debt reduced.
`message`	string	Result message.
`data.clientOrderId`	string or null	Echo of the customer identifier; `null` if omitted.
`data.requestIds`	array of strings	All system order identifiers generated for this request: one for a principal-only repayment, two when repayment covers both interest and principal.
`data.status`	string	Initial status in the submission receipt, `NEW`. Track each order for its actual execution state.
`data.amount`	string	Total repayment quantity accepted for the customer request, not the amount of each split record.
`data.currency`	string	Currency determined from the debt.

Split orders and actual funds movement

Record type	Amount	`from`	`to`
`REPAY_INTEREST`	Interest portion.	Actual customer-selected paying account.	Member whose interest debt is reduced.
`REPAY_PRINCIPAL`	Principal portion.	Actual customer-selected paying account.	Member whose principal debt is reduced.

For repayment, to identifies the account whose debt is reduced, not the destination receiving repayment funds. It is not LTP Lending Service. memberId always equals to.id; DMA to.accountType may be null when no destination wallet is identified.

Each split record has its own requestId, amount and execution status. They share clientOrderId and can share one transferId: the successful 41 repayment created two orders but only one 41 funds transfer. Do not count the same transfer twice. Repayment history records return debtId=null; retain the submitted debt ID separately.

Track all entries in requestIds, or query by clientOrderId and inspect every matching record. A single successful record is not proof that the entire split request succeeded. Execution statuses are NEW, PROCESSING, SUCCESS, FAIL; no extra orderId or nested items is returned.

Tracking and retries

After execution succeeds, query outstanding debts again. A fully cleared principal-and-interest debt is no longer returned; a partially repaid debt remains with its reduced amounts. Account-asset updates may arrive later than order status.

If submission times out, reconcile using the original customer identifier before another submission. Do not repeat a full repayment because one record is still processing or one split record failed; first check every order and the remaining debt to avoid another deduction.

Error codes

Check both HTTP status and JSON code. See Error Codes for shared errors. Field-validation messages are dynamic and can identify multiple fields.

Code	Meaning
`1001`	Required fields are missing; inspect `message`.
`1000`	Invalid JSON field type, such as an object instead of the `amount` string.
`100400`	Invalid parameter value, such as zero, negative or non-numeric `amount`.
`2000`	Signature verification failed.
`2003`	The API key level cannot call this endpoint.
`2004`	The key lacks a required permission; use `TRANSFER`.
`100429`	Request rate exceeded the limit.

An accepted repayment can later become FAIL. Order history currently provides no execution failure reason; retain both system request IDs and the customer identifier for support. Do not assume a failed submission receipt and a failed execution order are the same event.