Deposits

A deposit is when a user sells their skin to your platform. The user sends their item via a Steam trade offer, and you receive the value as balance.

The Deposit Flow

Fetch inventory

Call GET /client/inventory to get the user’s tradeable items with current offer prices.

User selects items

Display the inventory in your UI. The user picks one or more items to sell.

Initiate deposit

Call POST /client/trading/deposit with the selected items and their offer prices.

Trade offer sent

AssetPay creates a Steam trade offer for the user. The trade may pass through pending while the bot confirms the offer, then moves to active, sitting in the user’s Steam inbox awaiting acceptance.

User accepts

The user accepts the trade offer in Steam. The trade moves to hold.

Hold period (CS2 only)

For CS2, Steam enforces a 7-day trade protection period. The trade stays in hold until it ends. Rust trades skip this step entirely and transition active → completed directly.

Completed

After the hold period (CS2) or immediately after acceptance (Rust), the trade reaches completed. You receive a callback and credit the user’s balance.

Single-Item Deposit

POST https://api.assetpay.gg/client/trading/deposit
Content-Type: application/json
Authorization: CLIENT_TOKEN

{
  "items": [
    { "itemId": "a1b2c3d4-...", "price": 10.75 }
  ],
  "game": "730",
  "externalId": "dep_unique_123"
}

Multi-Item Deposit

You can deposit multiple items in a single trade. Pass them all in the items array:

POST https://api.assetpay.gg/client/trading/deposit
Content-Type: application/json
Authorization: CLIENT_TOKEN

{
  "items": [
    { "itemId": "a1b2c3d4-...", "price": 10.75 },
    { "itemId": "b2c3d4e5-...", "price": 5.20 }
  ],
  "game": "730",
  "externalId": "dep_multi_456"
}

amount defaults to 1. Rust items and items routed to a deposit provider only accept amount: 1; a larger amount is rejected with EXCEEDS_MAX_AMOUNT. A basket can be split into several trades internally (for example when some items are routed to a deposit provider). Each trade gets its own Steam offer and callbacks; the response is the largest trade, with the others in relatedTrades[], and only that primary trade carries your externalId. See Split baskets.

Request Fields

Field	Type	Required	Description
`items`	array	Yes	Array of items to deposit (min 1, max 250)
`items[].itemId`	string	Yes	Item ID from the inventory response
`items[].price`	number	Yes	Offer price in USD. Must match the current offer price returned by `/client/inventory`.
`items[].amount`	number	No	Quantity from a stacked inventory row (default: 1, max: 10000). Must be `1` for Rust and provider-routed items.
`game`	string	No	`"730"` (CS2) or `"252490"` (Rust). Defaults to `"730"`.
`externalId`	string	No	Your unique tracking ID (max 128 chars). Stored as `externalId` on the trade.
`isInstant`	boolean	No	CS2 only. Whether to request instant credit (default `false`). Rust deposits are always credited in full on `completed`.

Rate Limits

Two layers apply to /client/trading/deposit:

Per-merchant tier throttle (shared across all clients): 500 req/min verified, 5 req/min unverified.
Per-client guard (scoped per merchant + client Steam ID):
- Max 5 concurrent active deposits (not-yet-accepted: initiated | pending | active), rejected with TOO_MANY_ACTIVE_TRADES (HTTP 429).
- Max 10 deposits per 5-minute rolling window, rejected with RATE_LIMITED (HTTP 429).

These guard against runaway behavior on a single user. They run before pricing/inventory fetches, so a rate-limited request fails fast and cheap.

Response

The response contains the full trade object:

{
  "requestId": "...",
  "success": true,
  "data": {
    "id": "trade-uuid",
    "type": "deposit",
    "source": "client",
    "status": "initiated",
    "game": "730",
    "externalId": "dep_unique_123",
    "merchantId": "merchant-uuid",
    "clientUserId": "client-uuid",
    "clientSteamID": "76561198012345678",
    "clientTradeUrl": "https://steamcommunity.com/tradeoffer/new/?partner=...",
    "items": [...],
    "totalPrice": 10.75,
    "preCredit": 8.60,
    "pendingCredit": 2.15,
    "isInstant": true,
    "collateral": { "merchant": 0, "provider": 150.00 },
    "createdAt": "2026-03-04T10:00:00.000Z",
    "updatedAt": "2026-03-04T10:00:00.000Z"
  }
}

Instant Deposits

isInstant defaults to false, so a CS2 deposit is fully held unless you ask for instant credit. Sending isInstant: true fails with INSTANT_DEPOSITS_DISABLED if instant deposits are off for your account. When instant credit applies, AssetPay calculates how much of the deposit value can be credited instantly based on collateral, rather than waiting for the full 7-day hold period. Rust deposits are never split: they carry preCredit equal to totalPrice and pendingCredit 0, and are credited in full on completed. The split is decided when the deposit is created, so the creation response already includes:

preCredit - the amount credited instantly (USD) once the trade enters hold
pendingCredit - the remaining amount held until the hold period ends
collateral - breakdown of collateral sources

Callbacks carry preCredit from the start and pendingCredit once the trade enters hold (on Rust, once it reaches completed). collateral is only on the creation response; callbacks never include it. If isInstant is false or omitted, the entire amount waits until completed. The collateral field in the inventory response tells you the total instant credit available for that user before they start depositing.

External ID

The externalId field is your own tracking identifier. Use it to link AssetPay trades back to records in your system.

External IDs must be unique per trade. Reusing an ID will result in an EXTERNAL_ID_EXISTS error.

Balance Handling for Deposits

When to credit:

Event	Action
`hold`	CS2: credit `preCredit` amount (if using instant deposits)
`completed`	CS2: credit `pendingCredit` (the remaining held amount). Rust: credit `totalPrice`, since there was no `hold`
`reverted`	Reverse only what you have already credited: `preCredit` if the trade is reverted during `hold` (the normal case), `preCredit` + `pendingCredit` if it is reverted after `completed`

When NOT to credit:

Event	Action
`initiated`	Just acknowledge
`pending`	Just acknowledge. Offer created, bot confirmation pending
`active`	Just acknowledge. Steam offer sent, awaiting user acceptance
`failed`	No credit needed
`canceled`	No credit needed
`declined`	No credit needed (user declined the offer)

See the Callbacks guide for full details on processing each event.

Getting Started

Integration

Events & Webhooks

Reference

The Deposit Flow

Single-Item Deposit

Multi-Item Deposit

Request Fields

Rate Limits

Response

Instant Deposits

External ID

Balance Handling for Deposits

​The Deposit Flow

​Single-Item Deposit

​Multi-Item Deposit

​Request Fields

​Rate Limits

​Response

​Instant Deposits

​External ID

​Balance Handling for Deposits

The Deposit Flow

Single-Item Deposit

Multi-Item Deposit

Request Fields

Rate Limits

Response

Instant Deposits

External ID

Balance Handling for Deposits