# Balance

> Read your current balances and the ledger of every balance movement, for reconciliation.

## GET /api/v1/deposit/accounts/me

Your current balances. Check this before bulk operations rather than discovering a shortfall half way through.

**Request — no parameters**

```http
GET /api/v1/deposit/accounts/me
```

**Response — 200**

```json
{
  "resellerId": "7f3c1a28-9e4b-4c51-b1d2-0a6e5f8c3d94",
  "resellerName": "Apiname Reseller",
  "resellerGroupName": "Standard",
  "tryBalance": 12450.75,
  "usdBalance": 842.10
}
```

:::tip[What to do with it]
`resellerGroupName` tells you which `priceGroup` entry in the TLD and SSL catalogues applies to you — read that one and ignore the others.

Build a low-balance alert off `tryBalance` and `usdBalance`. Running out mid-batch means a wave of `Deposit:10001` errors and partially processed work.
:::

## GET /api/v1/deposit/transactions

Paged ledger of every balance movement. This is where you reconcile what you were charged against what you sold.

**Request**

```http
GET /api/v1/deposit/transactions?startDate=2026-10-01&endDate=2026-10-31
    &maxResultCount=100&sorting=creationTime%20desc
```

| Parameter | Notes |
| --- | --- |
| `startDate, endDate` | Date range. |
| `transactionTypes` | Filter by type — see the table below. |
| `productTypes` | Filter by product type. |
| `chargeType` | `0` credits only, `1` debits only. |
| `traceId` | Exact trace ID — the fastest way to find one operation. |
| `description` | Partial match, e.g. a domain name. |
| `amount` | Exact amount. |
| `skipCount, maxResultCount, sorting` | Standard paging. |

**Response — 200**

```json
{
  "totalCount": 318,
  "items": [
    {
      "traceId": "a7f3c92e-1b84-4d06-9512-6e8a2f7c3d41",
      "type": 1,
      "status": 1,
      "chargeType": 1,
      "amount": 11.40,
      "amountCurrency": "USD",
      "exchangeAmount": 0,
      "exchangeCurrency": 0,
      "productType": 1,
      "productId": "3c9a7e14-82b5-4d60-9f31-c7e8a05b6d42",
      "description": "Register: apiname.com",
      "period": 1,
      "creationTime": "2026-10-30T12:04:19",
      "resellerName": "Apiname Reseller",
      "oldBalance": 853.50,
      "balance": 842.10
    }
  ]
}
```

| type | Transaction type | type | Transaction type |
| --- | --- | --- | --- |
| 1 | `Register` | 7 | Refund |
| 2 | `Renew` | 8 | Deduction |
| 3 | `Transfer` | 9 | PreRegister |
| 4 | `Restore` | 10 | Shopping |
| 5 | `Deposit` | 11 | ResellerPayment |
| 6 | `Backorder` | 12 | InternalTransfer |

| status | Name | Meaning |
| --- | --- | --- |
| 1 | `Success` | Applied. |
| 0 | `Failed` | The movement did not take effect. |
| 2 | `Canceled` | Cancelled. |
| 3 | `Processing` | In progress. |
| 4 | `Refunded` | Refunded — e.g. an SSL whose 7-day window lapsed, or a hosting whose provisioning failed. |

`chargeType`: `0` Add (a credit — top-up or refund) · `1` Subtract (a debit — a purchase).

:::tip[Reconciliation tips]
- **`traceId` is your key.** Log it against the operation in your own system. When you need support, quoting it finds the transaction instantly.
- `productId` is the domain ID or certificate ID the charge belongs to — join on it to match charges to objects.
- A **refunded purchase appears as two rows**: the original debit with status `Refunded`, and a separate credit of type `Refund`. Match them on `traceId` so you do not double-count.
- `oldBalance` and `balance` let you verify the running total without recomputing it.
:::