Prerequisites
- A SkinShark merchant API key (
sk_live_...). Generate one in the dashboard. - Node 20+ (or any TypeScript runtime that supports
fetchnatively). - Optional:
openapi-typescriptfor fully typed responses.
1. Set up the client
2. Confirm credentials
GET /merchant returns your merchant profile, current fees, and wallet
snapshot. If this works, your key + IP allowlist + role are all good.
3. Create a sub-user
A sub-user is an isolated account under your merchant: own wallet, own Steam trade URLs, own trade history. Pass anexternalId you control so you can
reference this sub-user with your own ID later.
POST /merchant/users is API-key auth only — it rejects dashboard
sessions. This is intentional: provisioning happens server-to-server.4. Fund the sub-user
Move balance from your merchant spot wallet to the sub-user. Supply a uniqueIdempotency-Key so retrying after a network blip never double-funds.
5. Find an item to buy
Acting on behalf of the sub-user, search the catalog and grab a live listing. TheOn-Behalf-Of header tells the API to scope this call to that
sub-user — the call runs against their wallet, their Steam trade URL.
6. Buy the listing
Place the order with amaxPrice ceiling — if the listing’s price drifted
above this between fetch and buy, that item fails instead of overcharging
your sub-user.
7. Watch it execute
The happy path isinitiated → pending → active → hold → completed; a trade can
also terminate as failed, canceled, declined, or reverted (see trade
outcomes). Two ways to follow it:
- Poll merchant trades
- WebSocket (recommended)
- Webhook
Next steps
Authentication
Key types, IP allowlists, and the rules for what API-key auth can and
can’t do.
Acting on behalf of
The full sub-user model, how
On-Behalf-Of resolves, and what happens
when you forget it.Idempotency
Safe retries for funding, buying, and any operation that moves money.
Full Platform integration
The recommended pattern for SaaS reselling SkinShark to your own users.