A developer's guide to the PROXIES.SX reseller API: mint, cap, top-up, rotate, and delete per-customer keys, build proxy URLs, and wire Stripe or x402 (USDC) billing. Real endpoints, real curl and SDK examples — no hand-waving.
The PROXIES.SX reseller API lets you mint per-customer proxy keys programmatically. Authenticate with your psx_ reseller key in an X-API-Key header, then POST /v1/reseller/pool-keys with a trafficCapGB and expiresAt to get a customer pak_ key. Top-up, rotate, or delete keys with the same resource. The gateway meters every GB.
Everything starts with a single secret. Grab your reseller API key from your dashboard at client.proxies.sx/pool-proxy. It looks like psx_xxxxxxxx and identifies you, the reseller. Treat it like a password: it can mint keys and spend your wholesale balance, so it lives only on your server, never in client code.
The reseller endpoints all expect that key in an X-API-Key header. There is no OAuth dance — one header, every call. Wholesale bandwidth is billed at $4/GB, dropping toward $2.40/GB at volume, and you resell at whatever price you set.
A mint creates a per-customer key (pak_...) scoped by two fields:trafficCapGB (how many GB it may consume) andexpiresAt (an ISO timestamp). The customer uses that pak_ key as their proxy password — they never see your psx_ key. Here it is with raw curl:
curl -X POST https://api.proxies.sx/v1/reseller/pool-keys \
-H "X-API-Key: psx_YOUR_RESELLER_KEY" \
-H "Content-Type: application/json" \
-d '{
"label": "customer:alice",
"trafficCapGB": 10,
"expiresAt": "2026-08-04T00:00:00.000Z"
}'
# → { "id": "...", "secret": "pak_...", "trafficCapGB": 10, "expiresAt": "..." }Prefer typed calls? The official @proxies-sx/pool-sdk wraps the same endpoints. One client, one method:
import { ProxiesClient } from '@proxies-sx/pool-sdk';
const proxies = new ProxiesClient({
apiKey: process.env.PROXIES_SX_API_KEY!, // your psx_ reseller key
});
const key = await proxies.poolKeys.create({
label: 'customer:alice',
trafficCapGB: 10,
expiresAt: new Date(Date.now() + 60 * 86_400_000).toISOString(),
});
// Hand key.secret (pak_...) to the customer — they use it as the proxy password.
console.log(key.secret);Every reseller call lives under /v1/reseller/pool-keys and takes your X-API-Key header. Full reference in the Swagger docs.
| Method | Path | Purpose |
|---|---|---|
| POST | /v1/reseller/pool-keys | Mint a new customer key (pak_) with trafficCapGB + expiresAt |
| GET | /v1/reseller/pool-keys | List your customer keys and their usage |
| GET | /v1/reseller/pool-keys/:id | Fetch one key — cap, usage, status, expiry |
| PATCH | /v1/reseller/pool-keys/:id | Update a key (label, expiry, cap) |
| POST | /v1/reseller/pool-keys/:id/topup | Add GB to an existing key |
| POST | /v1/reseller/pool-keys/:id/regenerate | Rotate the secret, keep the same key id |
| DELETE | /v1/reseller/pool-keys/:id | Revoke a key — traffic stops immediately |
Once a key is minted, the customer connects through one gateway: gw.proxies.sx:7000. All the routing — pool, country, session, rotation — is encoded in the proxy username. Your psx_ reseller key is the username prefix; the customer's pak_ key is the password:
http://psx_RESELLER-{POOL}-{COUNTRY}-sid-{SESSION}-rot-{ROTATION}:pak_CUSTOMER_KEY@gw.proxies.sx:7000
# concrete example — US mobile, sticky session, hard rotation:
http://psx_ab12-mbl-us-sid-alice7-rot-sticky:pak_CUSTOMER_KEY@gw.proxies.sx:7000-mbl- stable 4G/5G mobile · -peer- residential · -any- auto-pick mobile, fall back to residential.
A two-letter country code (e.g. us, de, gb) targets the exit geography across 17+ countries.
The value after -sid- ties requests to one identity — reuse it to keep the same IP, change it to pick a fresh one.
sticky holds the IP for the session · hard forces a new IP each request · none leaves it to the gateway default.
Keys are living objects. When a customer buys more bandwidth, you top-up the cap instead of issuing a new key. If a secret leaks, you regenerate it in place — same id, new secret. When a subscription ends, you delete the key and traffic stops at once.
# Top up: add GB to an existing key
curl -X POST https://api.proxies.sx/v1/reseller/pool-keys/$ID/topup \
-H "X-API-Key: psx_YOUR_RESELLER_KEY" \
-H "Content-Type: application/json" \
-d '{ "trafficCapGB": 25 }'
# Rotate the secret in place (same id, new pak_)
curl -X POST https://api.proxies.sx/v1/reseller/pool-keys/$ID/regenerate \
-H "X-API-Key: psx_YOUR_RESELLER_KEY"
# Revoke — traffic stops immediately
curl -X DELETE https://api.proxies.sx/v1/reseller/pool-keys/$ID \
-H "X-API-Key: psx_YOUR_RESELLER_KEY"Use GET /v1/reseller/pool-keys to poll usage across all customers, or GET /v1/reseller/pool-keys/:id for one key's remaining cap — handy for usage bars and renewal nudges. Need to rename or extend? PATCH /v1/reseller/pool-keys/:id.
The whole reseller flow collapses to one rule: money clears → mint a key. For cards, that trigger is a Stripe webhook. Size trafficCapGB to whatever the customer paid for, then return the pak_ key.
// app/api/stripe/webhook/route.ts
import { ProxiesClient } from '@proxies-sx/pool-sdk';
const proxies = new ProxiesClient({ apiKey: process.env.PROXIES_SX_API_KEY! });
export async function POST(req: Request) {
const event = verifyStripeSignature(await req.text(), req.headers); // always verify!
if (event.type === 'checkout.session.completed') {
const s = event.data.object;
const gb = Number(s.metadata.gb); // GB the customer purchased
const key = await proxies.poolKeys.create({
label: `stripe:${s.customer}`,
trafficCapGB: gb,
expiresAt: new Date(Date.now() + 30 * 86_400_000).toISOString(),
});
await saveKeyForCustomer(s.customer, key.secret); // store + email the pak_ key
}
return new Response('ok');
}Autonomous agents don't do checkout forms. With the x402 flow, an agent pays in USDC over the HTTP 402 Payment Required handshake; when payment settles you mint a pak_ key capped to the amount paid. Same poolKeys.create() call, no human in the loop — a whole new class of customer for your storefront.
Don't want to wire all this by hand? The open-source proxy-reseller-kit ships the Stripe webhook, x402 flow, and a customer dashboard already wired to these endpoints. See the full reselling-business playbook for the end-to-end launch, or the white-label program if you want it fully branded.
It is the PROXIES.SX REST API for reselling mobile and residential proxies. You authenticate with your psx_ reseller key in an X-API-Key header and call /v1/reseller/pool-keys to mint per-customer keys (pak_...) with a trafficCapGB and expiresAt. The gateway at gw.proxies.sx:7000 then meters traffic against each key. You can also use the @proxies-sx/pool-sdk wrapper instead of raw HTTP.
POST to /v1/reseller/pool-keys with your X-API-Key header and a JSON body of { label, trafficCapGB, expiresAt }. The response includes the customer key (pak_...). With the SDK it is proxies.poolKeys.create({ label, trafficCapGB, expiresAt }). Hand the returned pak_ key to the customer; it is used as the proxy password.
http://psx_RESELLER-{POOL}-{COUNTRY}-sid-{SESSION}-rot-{ROTATION}:pak_CUSTOMER_KEY@gw.proxies.sx:7000. The username encodes your psx_ reseller key plus pool (-mbl-, -peer-, or -any-), country, a session id for stickiness, and rotation mode (sticky, hard, or none). The password is the customer pak_ key.
POST to /v1/reseller/pool-keys/:id/topup to raise the cap, or PATCH /v1/reseller/pool-keys/:id to change the label or expiry. To rotate the secret without minting a new key, POST /v1/reseller/pool-keys/:id/regenerate. To revoke access entirely, DELETE /v1/reseller/pool-keys/:id.
For cards, mint a key from your Stripe webhook handler when a payment succeeds, sizing trafficCapGB to what the customer bought. For autonomous agents, use the x402 flow: when a 402-gated request is paid in USDC, mint a pak_ key capped to the payment amount. Both paths are just one create() call after the money clears.
Clone the MIT-licensed kit, drop in your psx_ key, and mint capped customer keys on every sale — across real 4G/5G mobile + residential in 17+ countries, $4/GB → $2.40 at volume.