Official SDKs

BuyProxy ships open-source client libraries for eight languages. Each one wraps the same REST API with typed requests and responses, automatic retries, typed errors and helpers for the HTTP clients and browser-automation tools you already use — so generating a proxy, topping up bandwidth or running a reseller business is a few lines in your own stack. They're MIT-licensed, and prefer a terminal? There's a command-line tool too.

Choose your language

Before you start

A BuyProxy account has two kinds of API key. Both go in the X-API-Key header, and every SDK sends it for you.

Keys are shown once when you create them — store them in a secrets manager or environment variable, never in source control or in a browser. Revoke a key from the same page at any time. Requests with a suspended account's key return 403, and a reseller key stops working if the account drops below the Business plan.

The catalog (products) and account creation (signup, verify otp) work without a key.

Every SDK reads BUYPROXY_API_KEY from the environment, so in most programs you never pass the key at all:

export BUYPROXY_API_KEY=bp_key_xxxxxxxxxxxxxxxxxxxxxxxx

Product keys

Every top-up and allocation call takes a product key. Live prices come from the catalog call, so you never hard-code a rate.

Pay-as-you-go top-ups of 100 GB or more include a 10% volume bonus, and a single order is capped at 10,000 GB.

Generating proxies

Generation is free and instant — bandwidth is only consumed when traffic flows through a proxy. Every parameter is optional; omit one and the API's default applies. (Names follow each language's conventions, e.g. stickyMinutes / sticky_minutes / StickyMinutes.)

Each returned line is username:password@host:port with your targeting encoded in the username. Lines are on-demand and not persistent — generate fresh ones when you need them instead of storing them, because credentials can rotate when the pool moves.

Retries & rate limits

Every SDK retries for you, with the same rules:

• Rate limits (`429`) are always retried, waiting for the Retry-After the API sends (capped at 30 s) or an exponential back-off with jitter.
• Reads (GET) are also retried on 502/503/504 and on network failures.
• Writes are not retried on server errors — a repeated checkout or allocation must never double-charge — unless you attach an idempotency key (see below), which makes the retry provably safe.
• The default is 2 retries; set it to 0 to turn retries off. After the last attempt you get the typed error.

The API allows 60 requests per minute per key. Batch with count (up to 1000 lines per call) rather than looping over single-proxy calls.

Idempotency

Allocating bandwidth to a customer moves real GB, so it accepts an idempotency key. Send the same key twice and the second call moves nothing and returns alreadyApplied: true with the same result — safe to retry after a timeout or crash.

Use a value you can derive again from your own data (an order id, an invoice number), not a random value created per attempt. Keys are scoped to your account and may be up to 200 characters.

At a glance

How we keep them identical

All eight SDKs are verified against the same mock API and the same 28-request sequence: method, path, query string, JSON body, API key, idempotency key and user agent must match exactly, and 401 / 402 / 429 handling must behave identically. If we change an endpoint it lands in every SDK or the suite fails — so what you learn in one language carries to the others.

Source for everything lives in the open at github.com/DishantSinghDev2/buyproxy-sdks, including the conformance suite. Building something bigger? Start at the developer hub.