Authentication and response handling

The Reseller API uses one bearer token to authorize account and sub-user management. This token is different from the proxy auth keys returned for the reseller and its sub-users.

Send the bearer token

Include the token in the Authorization header on every API request:

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${PACKETSTREAM_RESELLER_TOKEN}" \
  'https://reseller.packetstream.io/reseller/my_info'

An absent, malformed, or unknown token produces an unauthorized response.

Protect the token

Treat the token as a secret with authority over reseller funds and sub-user credentials.

• Store it in a secret manager or protected environment variable.
• Never place it in client-side code, a mobile application, or software distributed to end customers.
• Redact the Authorization header from logs, traces, screenshots, and support messages.
• Use separate application permissions around operations that transfer balance or reset credentials.
• Reset the token from the authenticated dashboard if it may have been exposed.

A new or reset token can take up to five minutes to become available across the Reseller API service. Do not repeatedly reset it while waiting for propagation.

JSON requests

POST endpoints accept a JSON request body. Send an explicit content type:

curl --silent --show-error --fail-with-body \
  --request POST \
  --header "Authorization: Bearer ${PACKETSTREAM_RESELLER_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data '{"username":"u_example1234"}' \
  'https://reseller.packetstream.io/reseller/sub_users/view_single'

Amounts use integer USD cents. For example, 500 represents $5.00.

Response envelope

Every response uses the same top-level JSON shape:

{
  "status": 200,
  "message": "",
  "timestamp": 1784739600,
  "data": {}
}

Check the actual HTTP status before reading data. Do not automate recovery by matching the exact wording of message; use it for diagnostics.

Retry mutating requests carefully

The API does not accept an idempotency key. If a connection ends before your application receives a response, a POST operation may already have completed.

Before retrying:

1. query the relevant account or sub-user;
2. determine whether the intended state change is already visible;
3. retry only when repeating the operation is safe;
4. keep attempts and total retry time bounded.

This matters especially for sub-user creation because every invocation costs $0.10, including attempts that fail validation or collide with an existing username.

Continue with the complete endpoint reference.