Using the Binance API to Pull Your P2P Trade History for Bookkeeping

Every active Binance p2p merchant eventually hits the same wall: dozens of completed orders a day, and at some point you need a record of all of it — for your own books, for a client, or for tax filing. Scrolling the order history screen and copying numbers by hand works for a week. It does not work for a year. The Binance API can pull that same history programmatically, and it is worth understanding what it actually gives you before you build a workflow around it.

What the p2p API exposes

Your completed and cancelled p2p orders are available through the API as structured records — order identifiers, timestamps, the fiat currency and amount, the crypto asset and amount, the counterparty, and the order status. It is the same underlying data the app shows you one order at a time, just retrievable in bulk instead of by hand.

Reading permission is all this needs

Pulling trade history is a read-only operation. An API key scoped to Reading covers it — you do not need P2P Trading permission just to export records, only if the same key is also placing or managing ads. Keeping a key scoped to only what it actually needs is good practice here too: a bookkeeping script has no business holding trading permission it never uses.

What is missing from the raw export

This is the part merchants underestimate. The API gives you clean transaction records — it does not give you a tax return.

• There is no automatic cost-basis calculation. If you need gain or loss per trade in a home currency, that math happens after the export, not inside it.
• Fiat amounts come through in the currency the trade was actually done in. Converting everything to one reporting currency is a step you add yourself.
• Appealed and cancelled orders show up as their own records. If you are summing volume or revenue, filtering these out correctly matters — an unresolved appeal counted as a completed sale will throw your totals off.

Building a workflow that actually holds up

Pull on a schedule, not once a year

Querying a full year of history in one request at tax time is the hard way to do this. A script that exports new orders weekly or monthly into a running spreadsheet or database is far more reliable, and it means a bad month never turns into a scramble later.

Watch your timestamps

API timestamps come back in a fixed reference time, not your local timezone. Converting consistently before you file anything away matters more than it sounds — a trade that lands right at midnight can end up recorded on the wrong day if the conversion is skipped or done inconsistently across your records.

Expect to paginate

High-volume merchants will not get their entire history back in a single call. Any export script needs to walk through results in pages rather than assuming everything arrives at once, the same way any other bulk data pull against the Binance API does.

Where this fits next to a repricing bot

If you are already running P2P Auto-Pilot for repricing, the API key it uses is already scoped to Reading and P2P Trading and already connected to your account. A separate, Reading-only export script is a natural complement — it reads the same order history, just for your own records instead of for pricing decisions, and it never needs the ability to touch your ads at all.

The takeaway

The Binance API turns p2p bookkeeping from a manual, error-prone chore into a structured export — but it gives you records, not a finished ledger. Build the conversion, filtering, and cost-basis logic yourself, pull on a regular schedule instead of once a year, and treat timestamps and pagination as things to get right up front rather than problems to debug later.