Connect VPN provisioning to your own backend.

Start with a read-only credit check.

Your reseller API key identifies your account. Keep it on your server, outside public JavaScript, repositories and customer-visible pages. Send it in the request body over HTTPS.

This example reads your balance and plan pricing. It does not create a customer or spend credits. Set the environment variables in your server environment first; use the API address configured for your integration.

curl --request POST "$WL_VPN_API_URL/v1/reseller/credits" \
  --data-urlencode "api_key=$WL_VPN_API_KEY"

WL-VPN’s configured API base address: https://api-next.wl-vpn.com. The credit response includes your balance and plan entries such as 1_month, with credits_required, reseller_cost and monthly_cost.

Supported reseller workflows

Account creation requires api_key, plan, label and email. An optional username and password can be supplied; otherwise credentials are generated. Paid creation and renewal consume credits.

Plan keys are 24_hour_trial, 7_days, 1_month, 3_months, 6_months, 12_months, 24_months and 36_months. Check standard pricing and your account’s credit response when calculating costs.

Design a reliable order flow.

1. Confirm payment in your backend using your payment provider’s verified event.
2. Check that the order has not already been provisioned and that you have sufficient credits.
3. Create the VPN account and store the returned account reference securely against the order.
4. Deliver access through a secure customer channel and provide setup instructions.
5. Track renewals separately so the correct existing account is extended.

If a write request times out, check whether it succeeded before retrying. Do not assume creating an account is automatically idempotent. Treat returned passwords and API keys as secrets, and avoid logging them.

Automate renewals without creating duplicate accounts.

A renewal should extend the customer’s existing VPN username. Keep that username associated with the original customer record, then send api_key, username and plan to POST /v1/users/extend after your backend confirms the renewal payment.

1. Look up the customer’s existing account and check the purchased term.
2. Record the payment or order identifier in your own system so repeated payment notifications do not trigger repeated extensions.
3. Check the credit balance and account-specific plan cost before submitting the renewal.
4. Record a successful response and the resulting expiry date against that order.
5. If the result is uncertain, reconcile the account and payment records before retrying. Keep the order pending for review until you know whether access was extended.

Unused time on an active subscription is preserved: the extension starts from its current expiry. An expired subscription is extended from the time of renewal. Use the resulting date rather than calculating every month as 30 days.

Calling the endpoint does not schedule future payments or make the customer’s billing recurring. Your billing system must manage consent, future charges, failed payments and renewal notifications. Avoid overlapping manual and automatic fulfilment for the same order.

Handle failures before launch.

The API returns an authentication error for a missing or invalid reseller key. A provisioning failure can return HTTP 422. Handle non-success responses in your backend, keep a useful order status for support and avoid showing technical errors or secrets to customers.

Test a credit lookup, a trial account, a renewal and your own duplicate-order handling before enabling automatic paid orders. If you prefer to launch without a custom integration, start with the reseller panel and storefront.