Skip to content
ProxyRequest/ DOCS

Platform integration overview

The REST API prepares proxy access; it does not carry proxy traffic. Your backend creates identities, buys or assigns data, generates credentials and reads usage. Your customer’s application then connects to the HTTP/SOCKS gateway with those proxy credentials.

Choose how you fund access

Section titled “Choose how you fund access”
I run the platform and my own billingCreate a managed customer with independently funded access, record a verified external purchase with a privileged backend key, then check usage.
I resell traffic from my parent accountStart with a funded parent order, create a managed customer, assign a virtual quota and monitor both balances.
DecisionIndependent purchased dataShared-pool quota
What funds access?A paid package invoice for the recipientA parent root order already holding purchased data
What does the write do?Buys data and creates/updates an order and ledgerIncreases a child’s allowed consumption from the parent pool
Main operationPOST /invoicesPOST /users/{id}/data/add
Who can record external payment?Only a superuser can create status=paidA normal reseller cannot mark an invoice paid
What must be monitored?Usable purchased data and deadlinesChild remaining quota and parent usable data

Read how purchases and traffic fit together before choosing. A managed user can have its own purchased order; account hierarchy does not force shared accounting. Do not provision both models for the same user/package pair as if they were interchangeable.

If you only need your own proxy account

Section titled “If you only need your own proxy account”

Read your profile, select a package, buy it through checkout or wallet, and verify your order. Then generate credentials and make a gateway request. You do not need sub-users to use your own account.

Keep the boundaries explicit

Section titled “Keep the boundaries explicit”
Your checkout and customer records
        ↓ authenticated REST requests
ProxyRequest users → invoices/orders → purchased ledgers or child quotas
        ↓ generated proxy credentials
Your customer's HTTP/SOCKS client → proxy gateway → destination
        ↓ accounted traffic
Order balances + analytics + signed accounting webhooks

JWTs and API keys go to the API hostname. Proxy usernames/passwords go to gateway ports. A webhook signing secret verifies an inbound notification; it cannot authenticate either kind of request.

Build one complete lifecycle first

Section titled “Build one complete lifecycle first”
  1. Identify the actor, deployment mode, package and accounting model.
  2. Store local-to-platform user/package mappings.
  3. Create the purchase or quota and save the returned resource IDs.
  4. Verify the resulting order, generate credentials and send a real request.
  5. Check usage and balances after accounting updates arrive.
  6. Implement retries, depletion, expiration, renewal and cancellation before launching to customers.

Continue by task

Section titled “Continue by task”