Skip to main content
GET
Get Wallet
The pre-flight “can I afford this order?” check. All amounts are integer cents. POST /orders compares max_price + order_fee_cents against spendable_balance, not balance. Compare against the same figure here instead of discovering the shortfall as a 402.

Which balance to use

The two balances differ only for Zinc Connect accounts with reservations outstanding.
Under a zn_test_ key (or X-Test-Mode) this reads the sandbox wallet. Sandbox orders never draw it down.
Funds are added from the dashboard — see Ways to Pay.

Authorizations

Authorization
string
header
required

Zinc API key (Bearer zn_...)

Headers

authorization
string | null

Response

Successful Response

Response model for wallet data.

Beyond the raw balance this carries the two other numbers a client needs to answer "can I place this order?" without reimplementing the gate in POST /orders: the spendable balance that gate actually compares against, and the per-order API fee it adds on top of max_price. Both are server-derived on purpose — the fee is env-tunable and the two balances differ for Connect accounts, so a client computing either one locally would drift.

id
string<uuid>
required
user_id
integer
required
balance
integer
required
wallet_type
enum<string>
required
Available options:
api_consumption,
purchases
created_at
string<date-time>
required
updated_at
string<date-time>
required
spendable_balance
integer
default:0

Balance available to spend on orders, in cents. Excludes in-flight Connect hold reservations, which transiently inflate balance. This is the figure the order balance check compares against.

order_fee_cents
integer
default:0

Zinc's API fee per order, in cents. An order needs max_price + order_fee_cents available (plus the notifications add-on when the order opts into customer emails).

billed_by_invoice
boolean
default:false

True for bulk-deal customers, who are invoiced monthly. Their orders skip the wallet balance check entirely, so a low balance does not block them.