Users and data lifecycle

Reseller-managed users are account-scoped resources. Store the returned user ID as an immutable external identifier in your customer table.

Identity record

Keep your customer ID, ProxyRequest user ID, lifecycle status, and last synchronization time together.

Accounting record

Keep allocation operations and observed balances as append-only business events where your billing policy requires an audit trail.

User operations

Goal	Operation
List managed users	GET /users
Create a sub-user	POST /users
Retrieve one user	GET /users/{id}
Edit a user	PATCH /users/{id} or the documented update method
Reset proxy password	POST /users/{id}/password
Inspect user orders	GET /users/{id}/orders
Remove a user	DELETE /users/{id}

Exact method availability and body fields are defined per operation in the API Reference.

Allocate data

DATA INPUT HELPER

Convert allocation units to bytes

API UNIT: BYTES

Amount

Send this integer

1073741824

Copy bytes

Binary and decimal units are shown separately so the allocation is explicit.

1. Validate the commercial amount and unit in your billing service.
2. Convert it to integer bytes once.
3. Record a pending allocation with your internal operation ID.
4. Call the documented user data-add or data-subtract operation.
5. Store the confirmed response and mark the operation complete.

Subtraction is a financial action

Authorize it separately from ordinary profile edits. Log the operator or system reason and read the resulting state before telling the customer that a balance changed.

Handle uncertain outcomes

If the connection closes after a write was sent, the absence of a response does not prove the write failed. Before repeating it:

1. read the affected user or related order state;
2. compare the observed balance with the expected pre-operation value;
3. inspect your webhook and analytics records for the same time window;
4. escalate for manual review when the result cannot be proven.

This is safer than blindly retrying a byte addition and accidentally granting the same allocation twice.