What APIs you need for Shopify reconciliation

If you are scoping a reconciliation build or interrogating a vendor, this is the list. Five data sources, each with specific requirements, and the reconciliation is only as complete as its weakest link.

Nothing here is exotic. What makes the exercise useful is that most projects discover the gaps one at a time, in production.

One: the Shopify Admin API

What it must provide, all of which it does.

Orders with identifier and name, creation and payment timestamps, financial and fulfilment status, and currency. Cancellations distinguishable from refunds.

Line items with quantity, price, product and variant references, and cost per item where the merchant has entered it.

Discount allocations per line, not just the order-level total, so revenue attributes correctly by product — see Shopify discounts, taxes and line-level allocation.

Tax per line, as recorded rather than derived.

Shipping charged, as its own component.

Transactions with gateway name, kind, status and amount. This tells you which gateway to look in and confirms the payment was taken. It does not tell you the fee for a Malaysian store.

Refunds with their own line and tax detail, linked to the original order.

Fulfilments with tracking references, for joining the order to its courier charge.

Access requirements: read scopes for orders, products and fulfilments, plus approval for orders beyond the default historical window if you are bringing history — see the Shopify sixty-day order window.

Two: the payment gateway settlement data

This is the source that decides whether the project succeeds, and its adequacy varies enormously by provider.

Transaction-level records, not daily summaries.

A reference joining to your Shopify order. The single most important field in the entire build. Confirm it exists before anything else — see the gateway reference that joins everything.

Fees itemised per transaction. A batch total closes the payout and makes per-order margin impossible.

Payout grouping — which transactions constituted which payout, so a bank credit can be decomposed.

Refunds, chargebacks and reversals, identifiable as such and linked to their originals.

Reserve withheld and released, shown explicitly rather than as a residual.

The payout amount, date and reference, so it can be matched to the bank.

Transport is secondary. A scheduled file containing all seven reconciles completely; an API returning daily totals does not — see gateway API or settlement file.

Three: the bank

Transaction-level statement data with amount, date and narration, ideally via a feed rather than a manual download.

The bank's role is confirmation, not evidence. It tells you money arrived; the settlement report tells you what it was. Reconciling from the bank alone is the error the whole exercise exists to prevent — see automating bank reconciliation with AI.

If you run more than one gateway, a separate account per provider removes an entire class of ambiguity here — see reconciling two gateways into one bank account.

Four: the courier

Needed if delivery cost matters to your margin, which it usually does.

Consignment note references matched to shipments, joining to Shopify's fulfilment tracking numbers.

Charges per consignment, including any surcharges applied after the fact — weight corrections and remote-area charges are common and they arrive later than the shipment.

Cash on delivery remittances, if you offer it, which are a settlement stream of their own with their own timing — see managing cash on delivery.

Return shipments, so a returned parcel's cost attaches to the order it came back from.

This is the source most often skipped entirely, with courier invoices coded as a monthly expense lump. That closes the books and makes per-order delivery margin unavailable — see capturing the consignment note against the order.

Five: other sales channels, if you have them

If Shopify is one of several channels, each marketplace has its own settlement structure and none of them resemble a gateway payout. Marketplace fees are deducted inside the payout rather than charged separately, escrow rules delay release, and the reference schemes are entirely different — see running Shopify alongside Shopee and TikTok Shop and reconciling sales across multiple marketplaces.

The important design point: these are separate streams that consolidate at the reporting layer, not sources to be merged into one pipeline. Merging them produces a channel-blind view that cannot answer which channel is actually profitable — see which sales channel is most profitable.

What is genuinely missing, and what to do about it

Two gaps are structural rather than solvable by better integration.

Shopify holds no fee or settlement data for a Malaysian store. Shopify Payments is unavailable here, so the transaction fee, settlement currency and payout fields are empty regardless of scope or API version. The money side must come from the gateway.

No single source spans the whole chain. There is no one API that returns an order with its fee, its payout and its bank credit. The join is yours to build or to buy, and it is the substance of the work.

The practical consequence for a buying decision: ask a vendor which of the five sources they read. An answer covering Shopify and the bank is two of five, and the missing three are where the margin information lives — see why integration depth beats feature count.

Common questions

What data sources are needed to reconcile a Malaysian Shopify store?

Five: the Shopify Admin API for orders, line detail, discounts, tax, shipping and fulfilments; the payment gateway's settlement data for fees, payouts, refunds, chargebacks and reserve movements; the bank statement for confirmation that money arrived; the courier for consignment charges and any cash-on-delivery remittances; and each additional sales channel's own settlement data if you sell on more than one.

Which of those sources is most often inadequate?

The payment gateway's settlement data. It has to carry transaction-level records, a reference joining to your store's orders, fees itemised per transaction rather than as a batch total, payout grouping, identifiable refunds and chargebacks, and explicit reserve movements. Providers vary widely, and the gaps are what determine whether reconciliation can be automated at all.

Can Shopify's API alone reconcile a store in Malaysia?

No. Shopify Payments is not available in Malaysia, so the transaction fee, settlement and payout fields are empty regardless of which scopes are granted or which API version is called. Shopify supplies what was sold and confirms the payment was taken; what it cost and when you were paid must come from the gateway.

Why include the courier as a reconciliation source?

Because delivery cost is usually material to margin and courier charges do not arrive with the shipment. Weight corrections and remote-area surcharges are applied later, cash-on-delivery remittances form their own settlement stream, and return shipments have costs that belong to specific orders. Coding courier invoices as a monthly lump closes the books while making per-order delivery margin unavailable.

Related: the three-way match a Malaysian store needs · what it takes to build a Shopify connector · gateway API or settlement file