Mobile proxy
reseller kit

A mobile proxy reseller buys access from a supplier, packages that access under their own brand and supports the end customer. The supplier operates or sources the mobile network infrastructure. You decide what to sell, collect retail payments and keep customer connections working when upstream details change.

The Coronium Reseller Kit is an MIT-licensed starting point for that software. The reviewed Next.js example is a private operator dashboard. It lets your team map customers to proxies, buy and renew access, and receive signed lifecycle events. Its SQLite database stores customer records, modem assignments and webhook events on a persistent disk. [1] [2]

Use this page for the implementation. The reseller business playbook covers market selection and launch planning; reseller onboarding is the route for an account-specific commercial agreement.

Owning a dashboard and owning mobile hardware are separate decisions. An API reseller still operates the retail application and supports customers. A hardware operator takes on carrier contracts, power, cooling and recovery as well.

If hardware ownership is part of your plan, start with the proxy farm operating guide and hardware options. For an API business, compare the actual product contract in our mobile proxy provider guide. Dedicated device access, bandwidth billing and replacement terms are different products, even when they share the same country label.

Start with the working repository so the agent can inspect real routes and types. The existing client gives the agent concrete API fields, and the README specifies the required worker. The setup below pins the snapshot reviewed for this article; check upstream changes before adopting it for a new deployment. [1]

git clone https://github.com/bolivian-peru/coronium-reseller-kit
cd coronium-reseller-kit
# Review the latest changes, or reproduce the snapshot used in this guide:
git checkout e5e9030c4532f6380dffb2ba3a8f1bbd49735ff1
cd examples/nextjs-dashboard
cp .env.example .env
# Set the API key, operator login and webhook signing secret locally.
npm ci
npm run build
npm run start
# In a second terminal, from the same directory:
# npm run worker

Use a Node version supported by the checked-out package. The reviewed README specifies Node 20 or later. Configure CORONIUM_API_KEY, RESELLER_ADMIN_USER, RESELLER_ADMIN_PASSWORD and CORONIUM_WEBHOOK_SECRET in the server environment. Obtain the signing secret through Coronium support. Keep the local environment file out of version control. [2]

A prompt for adapting the existing application

This prompt defines the implementation and the tests. It does not authorize an agent to spend account balance. Keep purchase and rotation tools under the approval controls of your coding environment.

Work in my fork of https://github.com/bolivian-peru/coronium-reseller-kit.
Read AGENTS.md, llms.txt and examples/nextjs-dashboard/README.md first.
Use the existing operator dashboard as the foundation.

Implement only these requirements:
- My branding and operator-only customer/proxy management.
- Separate HTTP and SOCKS5 endpoint display; capability-aware actions.
- Purchases with a persisted order intent and stable Idempotency-Key.
- Explicit renewals with a fresh server quote and price confirmation.
- Signed lifecycle events in a durable inbox, plus the reconciliation worker.
- A durable customer/modem index and metadata re-stamping after replacement.

Keep API keys, webhook secrets and proxy passwords out of logs and client bundles.
Keep operator authentication. Do not add a public customer portal unless requested.
Use a persistent disk for SQLite and run one app instance plus the worker.
If targeting serverless, propose a shared durable database before deployment.
Read credentials from local environment configuration; do not print them.

Run read-only integration checks first. Test errors and duplicate events locally.
Report documentation conflicts rather than inventing the API contract.
Ask before a purchase, renewal, rotation or other account-changing test.
Finish with build results, test evidence and remaining production work.

Load the instructions in your AI tool

The API contract is the same whichever coding assistant you use. Instruction discovery differs, so confirm that the agent has read the kit before it edits payment or webhook code.

For tool access from an editor, see the Coronium MCP integration and machine-readable API resources. Enabling an MCP server can expose account-changing actions; repository context alone does not grant permission to run them.

1. Read stock and each protocol endpoint separately

Send X-Coronium-Proxy-Credentials: separate-protocol-v1 on stock and purchase requests when your client supports separate endpoints. The current public stock endpoint accepted this contract during our October 11 check. Inventory changes between a quote and a purchase; a successful read is not a reservation. [3] [4]

# Read-only. A stock response does not reserve a proxy.
curl --fail-with-body "https://api.coronium.io/api/v3/tariffs/available" \
  -H "X-Coronium-Proxy-Credentials: separate-protocol-v1"

When proxyEndpoints is present, read http and socks5 independently. Each can have its own host, port, username and password. Use flat fields only for legacy rows without that object. Gate actions on the advertised capabilities rather than a provider name. Do not offer replacement or automatic renewal for a proxy that does not support it. [4]

Match the requested country, carrier and rental term. Several tariff periods can point at the same devices, so adding tariff stock counts can overstate inventory. For customer setup, link to the SOCKS5 guide and use the proxy checker to diagnose protocol or authentication mistakes.

2. Persist purchase intent before sending money

Save the customer, tariff, approved amount, request body and order key before the request. The explicit idempotency contract replays the first successful response for the same key and identical request for 24 hours. Reusing the key with different request details is a conflict. Generating a new key after a timeout can create another purchase. [3]

# PAID REQUEST. First create and save purchase.json with your chosen tariff.
# Example purchase.json body (metadata is a JSON-encoded string):
# {"tariff_id":"YOUR_TARIFF_ID","modemCount":1,
#  "metadata":"{\"customer_id\":\"customer-007\"}"}

# Set ORDER_KEY once from your persisted order record.
# Reuse that key AND the exact file on every retry of this order.
curl --fail-with-body \
  "https://api.coronium.io/api/v3/payment/buy-with-account-credit" \
  -H "Authorization: Bearer $CORONIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Coronium-Proxy-Credentials: separate-protocol-v1" \
  -H "Idempotency-Key: $ORDER_KEY" \
  --data-binary @purchase.json

The exact field is modemCount. Send metadata as a JSON-encoded string, including an internal customer identifier. Keep names, email addresses and other personal details in your own customer system unless the upstream mapping needs them. The kit client implements this encoding. [1]

Reconcile the actual charge from billing.charged_usd, with subtotal_usd and discount explaining the difference. A submitted coupon is not evidence that a discount was applied. Store the returned charge and the supplied proxies together in your order ledger. [5]

3. Quote an owned proxy before renewing it

Use POST /payment/renewal-quote for the exact modem and number of days. Show the fresh quote before charging and carry the same coupon into the renewal request. A tariff for the same country can belong to a different carrier or product. The example performs explicit renewals; it does not implement your customer's recurring retail subscription. [2] [5]

Account credit and BTC are separate payment lanes in the reviewed client. Do not infer the spendable balance from a generic wallet total. A support process must also handle customer cancellation before your next upstream purchase or renewal.

4. Verify, store and deduplicate lifecycle events

Lifecycle events carry event_id, event and event-specific fields under data. Verify X-Coronium-Signature against the exact raw body before parsing. Insert the event into durable storage using a unique event ID, then return a successful acknowledgment. Process it in a worker that can resume after a crash. [3] [7]

// Signature verification only; not a complete webhook receiver.
import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifySignature(rawBody, header, secret) {
  if (!secret || typeof header !== 'string') return false;
  const expected = 'sha256=' + createHmac('sha256', secret)
    .update(rawBody).digest('hex');
  const a = Buffer.from(expected);
  const b = Buffer.from(header);
  return a.length === b.length && timingSafeEqual(a, b);
}

// Then: validate envelope -> durable insert keyed by event_id -> 2xx.
// Process the saved event in a worker. A failed insert must not return 2xx.

The full receiver implementation also validates the envelope and limits payload size. Keep payloads and proxy passwords out of logs. Log an event ID, processing outcome and request ID instead. Duplicate delivery must not duplicate customer credits or notifications.

For modem.replaced, find the customer through the old modem's durable local mapping. Confirm the new modem belongs to your account, update the assignment and restore metadata.customer_id on the replacement. Replacement metadata is not inherited. Notify the customer through your own workflow; the starter does not send customer email or update a customer's browser configuration. [2] [6]

Replacement depends on product capability and available stock. A modem.dead or failed-purchase event needs an operator response. Poll expiry and health as a reconciliation check, and test recovery when events arrive late or out of order.

5. Read rotation results, then tell the customer what happened

The authenticated POST /modems/{id}/restart is documented as synchronous. Both a changed IP and an unchanged IP can return HTTP 200. Branch on rotated and read ip; the old ?sync=true example and new_ip field are not the current documented contract. Authentication, validation and infrastructure errors still need their own handling. [3]

// Successful HTTP response examples. They describe different outcomes.
{ "result": "ok", "rotated": true,  "ip": "198.51.100.21" }
{ "result": "ok", "rotated": false, "ip": "198.51.100.20" }

// After checking authentication and HTTP errors:
if (body.rotated === true) showConfirmedIP(body.ip);
else showRotationFailure(body.message);

The token-based rotation route has a separate status contract. Follow the reference for the exact route you call, respect cooldowns, and do not loop rotations when the carrier retains the same IP. The IP troubleshooting guide helps distinguish a connection failure from an account restriction that a new address cannot resolve.

Requests below are relative to https://api.coronium.io/api/v3. Keep the account Bearer key on your server. Use the live API reference alongside the reviewed kit client; the client also shows the explicit renewal routes. Check each operation's schema before implementing its request body.

Markup compares the selling price with the supplier cost. It leaves out payment fees, support and customer acquisition. Contribution is what remains after the variable costs you enter; fixed costs still need to be covered. Use an actual account quote and the billed charge for your country, carrier and term.

In the example, a $99 sale and $59 supplier cost create a $40 spread. After a 3% processing fee, $8 of support and $2 of other variable costs, contribution is $27.03 per port. Ten paid ports contribute $270.30, leaving $210.30 after $60 of fixed monthly costs. These are arithmetic examples, not measured business results.

Include idle stock, refunds, failed collections and chargebacks in your own model. Price trials using their actual cost and measure conversion from your customers; this guide does not assume a paid-trial conversion rate. The bulk pricing guide explains purchasing models, while reseller onboarding can confirm current account terms.

Test the parts that can lose an order, expose a credential or leave a customer offline. Keep read-only checks separate from actions that spend balance or alter a running connection.

1. Protect the operator application

   Require login for pages and API routes, serve HTTPS, rate-limit login attempts and confirm that anonymous requests cannot retrieve credentials. Test cross-origin mutations.

2. Verify configuration without spending

   Use the kit’s examples/verify-integration.mjs from the repository root with the API key supplied through your local environment. It reads stock, account state and configuration by default. Do not print the key.

3. Preserve customer ownership

   Map a customer to each purchased modem and backfill existing assignments before enabling replacement reconciliation. A customer portal must authorize every read and action on the server.

4. Test one approved paid order

   Confirm the tariff, total and payment lane first. Save the stable order key, reconcile the response and verify each supported protocol. Keep a timeout in an unresolved state until reconciled.

5. Exercise the webhook inbox

   Test a valid signature, a tampered body, an unsigned event and duplicate delivery. Verify that a failed database write produces an error response and that a worker restart resumes pending work.

6. Rehearse a replacement and a failure

   Use fixtures for the old/new modem mapping, metadata restoration and no-stock outcome. Verify customer notification through your own system and keep unknown assignments visible for review.

7. Verify renewals and expiry

   Quote the exact owned modem, confirm the price and use a stable renewal key. Check cancellation behavior and expiry reconciliation without assuming an advance-expiry webhook will arrive.

8. Restore before you scale

   Restore a backup to a separate environment, confirm mappings and event history, and prove the worker runs after deployment. Add shared durable storage before running multiple app instances.

Record the response request_id when asking support to investigate an order. Send the event ID and processing state for webhook problems. Avoid including account keys or full proxy credentials in tickets.

Confirm that your supplier agreement covers the resale model you intend to offer. Coronium's Terms and Conditions prohibit abuse including unauthorized access, spam and service disruption. Publish customer terms that explain permitted use, suspension, refunds, renewal and the support you provide. An open-source software license does not replace a service agreement.

Define how you identify customers, receive abuse reports and disable the affected access. Store only the personal data needed for those operations, restrict staff access to proxy passwords and document retention. Have jurisdiction-specific tax, privacy and resale obligations reviewed for the markets you serve; this implementation guide does not establish a universal legal exemption.

Coronium publishes this guide about its own kit. We reviewed repository commit e5e9030, dated October 7, against the public API documentation on October 11, 2026. The source links below pin implementation claims to that snapshot. The repository's current branch can change after publication.

Validation covered the public stock request, example request syntax, signature verification with signed and tampered local fixtures, and calculator arithmetic. We did not make a paid purchase, renew a subscription, rotate a live modem or prove authenticated webhook delivery for this article. Setup guidance follows the reviewed repository; it is not a claim that every deployment target was tested.

1. 1.
   Coronium kit: reviewed source and MIT license

   Repository snapshot reviewed October 11, 2026; commit dated October 7.

2. 2.
   Operator dashboard: setup and deployment requirements

   Persistent SQLite, operator authentication, reconciliation worker and customer-portal limits.

3. 3.
   Live Coronium API reference

   Authentication, request identity, rotation and webhook contracts. Retrieved October 11, 2026.

4. 4.
   Stock and separate protocol credentials

   Credential negotiation, endpoint capabilities, rental terms and stock counting.

5. 5.
   Billing and renewal reconciliation

   Itemized charges, coupons, carrier matching and webhook receipt fields.

6. 6.
   Webhook integration and customer mapping

   Signed lifecycle envelopes, deduplication, replacement metadata and recovery limits.

7. 7.
   Receiver implementation

   Raw-body signature verification, envelope validation and durable insert before acknowledgment.

8. 8.
   Codex project instructions

   Official AGENTS.md documentation, checked October 11, 2026.

9. 9.
   Claude Code project memory

   Current AGENTS.md and CLAUDE.md loading rules, checked October 11, 2026.

10. 10.
    Cursor rules

    Project instructions and nested AGENTS.md, checked October 11, 2026.

11. 11.
    Windsurf / Devin Desktop project instructions

    Windsurf documentation redirects here; workspace and directory scoping checked October 11, 2026.

12. 12.
    Aider read-only conventions

    Explicitly load instruction files with /read or --read.

13. 13.
    GitHub Copilot repository instructions

    Instruction support depends on the Copilot surface; checked October 11, 2026.