Your first 100 GB: what a partner buys, allocates and reclaims in week one

2026-10-02 · Bazyl

By the end of this post you can run a partner account's first week yourself: buy the pool, read it, fund a customer, top them up, and take back what a lapsed one left behind. Five calls, one ledger.

The mistake I see most is in the first customer call. The partner creates the account, pastes the credentials into a Discord DM, and the buyer tests them within ten seconds and reports a 407. New credentials need about a minute, and the API says so in the response. Read that field.

The sale: 100 GB by bank transfer

Your first wholesale order is 100 GB.

After that you top up in whatever size matches your sales. Wholesale starts at $0.50 per GB; the exact band depends on your volume and I quote it when you ask. I'm not printing a second band here, because yours depends on what you buy.

You pay by bank transfer against an invoice. A card link is possible if you prefer it. The gigabytes land in your pool when the sale is recorded, and from then on they are yours: no monthly fee, no branding fee, and nothing in the pool ever expires.

The API counts in megabytes, and 1 GB is 1,000 MB everywhere on our side. So the first order shows up as 100,000 MB. If you want the margin math before the transfer, the worked example is a short read.

Read the pool: GET /me

Make GET /me the first call you send with the key. It returns your pool under pools[], your customer counts, the active keys on the account, and your rate limit.

curl -s "https://api.basilproxies.com/api/reseller/v1/me" \
  -H "Authorization: Bearer $BASIL_PARTNER_KEY"

Read the entry in pools[] whose product is residential2. After the first order its balanceMb is 100000. The same block carries a pendingSaleMb field; on the residential pool a purchase either lands or is refused outright, so that field reads 0 and stays 0.

The rate limit is 120 requests a minute by default. It goes up on request, and a drop day is a normal reason to ask.

The first customer: one call

A customer is created and funded in one call. POST /customers with initialGb, "product": "residential2" and an Idempotency-Key answers 201 with the account's credentials, and the gigabytes move from your pool to the customer in that same call.

# They paid you: create the customer and fund them from your pool in one call.
curl -s -X POST "https://api.basilproxies.com/api/reseller/v1/customers" \
  -H "Authorization: Bearer $BASIL_PARTNER_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1042" \
  -d '{"displayName": "discord: kwsz_", "initialGb": 20, "product": "residential2"}'
# 201 → "balanceStatus": "active",
#       "credentials": { "username": "ck_9m2xq7t", "password": "…",
#                        "hosts": { "eu": "…", "us": "…", "ap": "…" },
#                        "ports": { "rotating": 4242, "sticky": 4243 },
#                        "warmupSeconds": 60 }

Four things in that exchange decide what you do next.

warmupSeconds is 60. New credentials can answer 407 for about a minute while the gateway picks them up, so don't hand the string to someone who will test it instantly. Post it with "ready in a minute", or hold it for sixty seconds first. A 407 in that window is not a bad password.

balanceStatus is active on a clean run. pending means the move is committed and lands within minutes; nothing to do. failed means the customer exists but the gigabytes didn't move, and allocationError says why. Fix the cause, then retry with balance/add. Never re-POST the customer, or the same buyer ends up with two accounts.

If the pool can't cover initialGb, the answer is 409 INSUFFICIENT_POOL and no customer is created. Nothing to clean up.

The Idempotency-Key is your own order id. Send one on every POST and DELETE. A retry with the same key returns the stored response, marked Idempotency-Replayed: true, and never moves gigabytes twice. A stored 4xx is replayed too, so once you've fixed the cause, retry with a new key.

The second sale: the same customer

When that buyer comes back, top up the same customer. POST /customers/:id/balance/add moves gigabytes from your pool to them; their credentials don't change and their proxy strings keep working.

curl -s -X POST "https://api.basilproxies.com/api/reseller/v1/customers/$CUSTOMER_ID/balance/add" \
  -H "Authorization: Bearer $BASIL_PARTNER_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1088" \
  -d '{"amountGb": 10, "product": "residential2"}'

Never create a new customer per order. It doubles your account count, splits one buyer's usage across accounts, and leaves them juggling two strings. One buyer, one customer id, many top-ups.

A lapse: reclaim what's left

When a plan lapses, take back what's unused. balance/remove with "amountMb": "all" moves everything the customer still holds back into your pool. The account stays and can be topped up again.

curl -s -X POST "https://api.basilproxies.com/api/reseller/v1/customers/$CUSTOMER_ID/balance/remove" \
  -H "Authorization: Bearer $BASIL_PARTNER_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: lapse-1042-2026-10-09" \
  -d '{"amountMb": "all", "product": "residential2"}'

suspend does the same reclaim and freezes the customer on top. kill is suspend plus a password rotation, for abuse. DELETE is kill plus a DELETED status; the record stays, and reactivate answers with fresh credentials. Reclaim returns what is left, not what was burned: a customer who used 18 of their 20 GB hands back 2 GB.

What the ledger shows after the week

Every move above is a row in GET /ledger, newest first, each one a signed MB delta with its product and kind. The week above reads, oldest to newest:

• SALE, +100,000 MB: your wholesale order
• ALLOCATE, −20,000 MB: the first customer
• ALLOCATE, −10,000 MB: their top-up
• RECLAIM, +2,000 MB: the lapse

Add them up and you get 72,000 MB, which is what GET /me reports as balanceMb. The pool balance is the sum of the ledger, always. The only other kind you'll meet is ADJUST, a correction in either direction.

What we don't do

Your customers never meet us. There is no Basil dashboard, login or email for a partner's end customer: you hand out the string, you answer their questions, you take their money however you collect it. We see neither them nor it.

Support for you is me, by ticket. Onboarding is same-day: your partner account, your first key and your first sale are three actions on my side, and the key works the moment it exists.

When you're ready for the first 100 GB, apply on the partner page.