After a top-up, confirm that funds posted. After an order, confirm that a charge posted. Use the official Transactions docs rather than reading only today's wallet figure. The docs split common records into two families: consumption records, and recharge or balance-adjustment records. When you reconcile, filter with the platform order number first; that recommendation also appears in Best practices.
This is not a second balance guide, and it is not the USDT TRC20 top-up flow itself. Balance is the current wallet. This page is the history. For remaining dynamic traffic, see traffic quota. Authorized targets only. Not supported in mainland China.
What to prepare
| Item | Where it comes from |
|---|---|
| An access token or a signed-in console | API calls need a valid token; see login and token |
| An order number, if you have one | The platform order number from create or renew; use ORDER_NO_EXAMPLE only as a placeholder |
| A date range | Query dates use YYYY-MM-DD |
| A product-type filter | Consumption records accept order_type=static or dynamic |
Placeholders only (not production): token TOKEN_EXAMPLE_NOT_REAL, order number ORDER_NO_EXAMPLE. Do not treat sample order numbers in the docs as your live order.
Keep the two ledgers separate
| Ledger | Endpoint | What it helps you confirm |
|---|---|---|
| Consumption | GET /open/app/user/transactions | Spend from dynamic or static orders |
| Recharge and adjustments | GET /transaction/agent/transactions | Whether a top-up or balance adjustment posted |
| Current balance | Balance API or console | The wallet after a record posts; see check balance |
The docs say resellers can view their own records and those of downstream users; regular users can view only their own records. This page teaches a buyer to reconcile their own history. It is not a team sub-account or reseller onboarding guide. Those APIs live in the Accounts docs and target downstream or reseller integrations, not a typical console buyer path.
Consumption filters
Common query parameters are listed below. Pagination uses page and page_size, with a maximum of 100 rows per page.
| Parameter | Meaning |
|---|---|
page, page_size | Page number and page size; page_size maxes out at 100 |
order_type | static or dynamic |
type | Transaction type (use the live API values; this page does not invent an enum) |
start_date, end_date | Date range in YYYY-MM-DD |
order_no | Filter by order number |
keyword | Search remarks, type, order number, or username |
username, target_user_id | Documented filters; a regular user still only sees records inside their permission scope |
The recharge and adjustment endpoint documents filters for order_no, a date range, pagination, and an optional user_id limited by account permissions. Do not use the consumption endpoint to prove a top-up, and do not use the recharge endpoint to prove order spend.
Example: consumption records
export ZTPROXY_BASE="https://backend.ztproxy.net/api"
export ZTPROXY_TOKEN="TOKEN_EXAMPLE_NOT_REAL"
curl -X GET "$ZTPROXY_BASE/open/app/user/transactions?page=1&page_size=10&order_type=static" \
-H "Authorization: Bearer $ZTPROXY_TOKEN"Switch order_type to dynamic for dynamic spend. To reconcile one order, add the documented order_no parameter with your real order number, not ORDER_NO_EXAMPLE. If the console has a billing or history screen, follow the live labels, but still cross-check against the API or an export.
Compliance and scope
Use this only on authorized targets. Do not treat this page as a way to inspect someone else's account. Prices follow the console and Pricing (dynamic about $0.40/GB, about $0.20/GB for the 100 TB package; static shared about $1.50 and exclusive about $5 per IP per month). USDT/USDC are available; Visa/Mastercard are still being applied for. Not supported in mainland China.
FAQ
Why are spend and top-ups on different endpoints?
Official docs split them. Consumption covers charges from orders. Top-ups and adjustments are a separate ledger. Pick the endpoint that matches the event you are reconciling.
Can a regular user see a teammate's records?
The docs say regular users can view only their own records. This page is not team sub-account administration.
How many rows can one page return?
The consumption docs cap page_size at 100. Best practices also say not to request more than 100 rows per page.
What date format should I use?
YYYY-MM-DD. Do not guess with timestamps or localized date strings.
I topped up, but nothing appears yet.
Confirm the top-up order status in USDT TRC20, then check recharge and adjustment records, then check the balance. Do not immediately create another top-up order.
Can billing history prove a static IP is ready?
It can only help you confirm a charge or adjustment. Whether the static resource is provisioned still depends on the order list and instance status; see buy a static IP. queued: true is not the same as ready.
Can I search if I do not have an order number?
Yes. Start with dates, product type, or a keyword. To reconcile one order, still use the platform order number returned at purchase time.
Where do prices come from?
Follow the console and Pricing. Posted amounts in the ledger are what settled, not a marketing sample.
Next steps
- Choose consumption or recharge/adjustment records, then filter by order number or date.
- Cross-check account balance.
- If you still need to buy, go to dynamic traffic or a static IP.