Fees

Your fee schedule is specific to your account. Read it in the web app under My Profile → Fee Schedule: the same menu the API key lives in. That page is the authority on your rate and on when you are charged; this page only explains how the resulting fees appear in the API.

Fee amounts are dollar strings, like every other money field in the API: a minimum of four decimal places, with any further precision preserved. You will find them on trade_fee and total_fee on a fill, fee on a settlement, and the potential_order_trade_fee projection on GET /api/v1/account/market_stats.

Fee history

GET /api/v1/portfolio/fees lists the fees charged against your account, newest first. It is the one place every fee appears, whichever way your account is charged; the other fee fields above each show one fee in the context of a single fill or settlement.

Each row’s amount is the signed effect on your balance, so you total what you have paid by summing amount rather than by reading each row’s type: a fee is never positive, and a fee_refund is never negative.

Fees that are only projected (held against your available balance but not yet charged) never appear here. GET /api/v1/account/market_stats is where you see those.

Telling one fee from another

A row does not name what kind of fee it is. Use the references it carries:

Row carries	What it is
settlement_id	The fee for that settlement. The same fee appears as a positive fee on that row in GET /portfolio/settlements.
market_id but no settlement_id	A fee tied to that one market: a trade fee, or a charge applied when the market settled.
Neither, plus an event_id	A single charge covering a set of related markets on that event, rather than any one of them.

Every row fills in the narrowest reference that applies and leaves the rest null, so a null is the normal case, not missing data.

That is why event_id is null on the first two kinds. They already name a single market, and you read that market’s event from event_id on GET /api/v1/markets. event_id is populated only on the third kind, where no one market applies and the event is the narrowest thing there is to name. fee_id behaves the same way: present on trade fees and on the set-of-markets charge, null on a fee that came from a settlement.

So a settlement fee arrives with market_id and settlement_id set and event_id and fee_id both null. That row is complete.

One thing not to infer from fee_id: it does not pair a refund with the charge it reverses. A fee_refund is recorded as a fee in its own right and carries its own fee_id, so joining the two on it finds nothing. A refund always concerns a single market, so market_id and the ordering are what relate it to the charge it offsets.

A fee can legitimately be zero

A fee of "0.0000" is a real entry, not a placeholder for a missing value. It means the fee was assessed and came to nothing.

You will only see it on the last row type in the table above: the one charge covering a set of markets. Because that fee is a percentage of your total profit across the whole set, it cannot be worked out until every market in the set has settled, and it comes to zero when that total is zero or negative, or when your rate is zero. A positive total is never charged less than "0.0100".

The other row types are simply absent when there is no fee to charge.