Wallet History

View your paginated balance transaction ledger with filters and summary.

Returns your paginated wallet transaction history: deposits, order deductions, refunds, and manual adjustments. Includes an aggregate summary for the filtered range.

Endpoint

GET/api/v1/wallet-history

Request Headers

Headers

Parameter	Type	Required	Description
`X-Api-Key`	String	Yes	Your API Key.
`X-Timestamp`	String	Yes	Current Unix timestamp in ms.
`X-Signature`	String	Yes	HMAC-SHA256 signature. Sign timestamp only.

Query Parameters

Query Params

Parameter	Type	Required	Description
`page`	Number	No	Page number (1-based, default: 1).
`limit`	Number	No	Items per page (1-100, default: 50).
`type`	String	No	Filter: deposit, deduction, refund, adjustment. Omit for the complete ledger.
`start_date`	String	No	Start date (YYYY-MM-DD).
`end_date`	String	No	End date (YYYY-MM-DD). Max 90-day range.

Response

{
"success": true,
"data": {
  "transactions": [
    {
      "transaction_id": "a1b2c3d4-...",
      "type": "deposit",
      "amount": 1000000,
      "balance_before": 500000,
      "balance_after": 1500000,
      "description": "Balance Top-up - BCA-12345678",
      "ref_id": "BCA-12345678",
      "created_at": "2026-05-14T08:00:00.000Z",
      "status": "approved"
    },
    {
      "transaction_id": "e5f6a7b8-...",
      "type": "deduction",
      "amount": -25000,
      "balance_before": 1500000,
      "balance_after": 1475000,
      "description": "Order Deduction",
      "ref_id": null,
      "created_at": "2026-05-14T10:30:00.000Z",
      "status": "approved"
    }
  ],
  "summary": {
    "total_topup": 1000000,
    "total_deductions": 25000,
    "net_change": 975000
  }
},
"meta": {
  "total": 42,
  "page": 1,
  "limit": 50,
  "total_pages": 1,
  "has_more": false
}
}

Transaction Types

Type Reference

Parameter	Required	Description
`deposit`	No	Balance top-up (positive amount).
`deduction`	No	Order charge (negative amount).
`refund`	No	Failed order refund (positive amount).
`adjustment`	No	Manual admin adjustment.

Amount Sign Convention

Deductions are always returned as negative numbers (e.g., -25000). Deposits and refunds are positive. This lets you render a clean transaction ledger without extra logic.

Transaction Status

Every transaction carries a status. Only entries that actually moved your balance are returned; deposit requests still awaiting approval, and rejected ones, never appear here.

Status Reference

Parameter	Required	Description
`approved`	No	The movement stands. This is the status of almost every entry.
`voided`	No	A deposit that was later cancelled. Returned with the credit it made when it was approved, and paired with a separate deduction entry for the clawback.

Reading a voided deposit

A void produces two entries: the original deposit (status: "voided", positive amount, the credit it made on approval) and a deduction for the amount clawed back. Read them together: the pair nets to what your balance actually kept. Summing the entries as they are returned is always correct; no special handling required.

Summary Semantics

summary is aggregated across the entire filtered range, not just the page you requested; page through the transactions all you like, the totals do not change.

Summary Fields

Parameter	Type	Required	Description
`total_topup`	Number	No	Sum of every entry that increased your balance in the range (deposits, refunds, positive adjustments, voided-deposit credits).
`total_deductions`	Number	No	Sum of every entry that decreased your balance in the range, as a positive magnitude.
`net_change`	Number	No	total_topup − total_deductions.

Filtering with type

When type is set, summary covers exactly the entries returned for that filter, so the totals and the rows always describe the same set. type=deduction returns your order charges; a deposit clawback is a cancellation rather than an order, so it appears only in the unfiltered ledger alongside the credit it reverses.

Ordering

Entries are returned newest first, ordered by created_at descending with transaction_id as a tiebreaker. That ordering is total and stable, so paging through your full history never repeats or skips an entry; safe to use for incremental reconciliation.

Example cURL

API_KEY="algan_live_..."
API_SECRET="sk_live_..."
TIMESTAMP=$(python3 -c "import time; print(int(time.time() * 1000))")
SIGNATURE=$(echo -n "${TIMESTAMP}" | \
  openssl dgst -sha256 -hmac "${API_SECRET}" | awk '{print $2}')

curl -s "https://algan.id/api/v1/wallet-history?page=1&limit=10&type=deposit" \
  -H "X-Api-Key: ${API_KEY}" \
  -H "X-Timestamp: ${TIMESTAMP}" \
  -H "X-Signature: ${SIGNATURE}"

Example (Node.js)

const crypto = require('crypto');
const API_KEY = 'algan_live_...';
const API_SECRET = 'sk_live_...';
const timestamp = Date.now().toString();
const signature = crypto.createHmac('sha256', API_SECRET).update(timestamp).digest('hex');

const res = await fetch('https://algan.id/api/v1/wallet-history?page=1&limit=20', {
  headers: { 'X-Api-Key': API_KEY, 'X-Timestamp': timestamp, 'X-Signature': signature },
});
const { data, meta } = await res.json();
console.log(`Net change: Rp ${data.summary.net_change.toLocaleString()}`);