Give Resellers a Fusion-Compatible API at /api/index.php

Most IMEI unlock store owners reach the same point. Retail customers are ordering through your site, and then other shops ask whether they can plug into you directly. They don't want to log in and type orders by hand. They want their own panel to talk to yours. That is what a reseller API is for, and in this industry the format most buyers already know is the Fusion API.

This article covers why a Fusion-compatible endpoint at /api/index.php matters, what it should do, and what to check before you offer it to your reseller network.

Why resellers ask for a Fusion-compatible API

Many small and mid-sized unlock shops already run software that speaks the DHRU Fusion API format. Their panels, scripts and order tools are built around it. When they add a new supplier, the easiest path is one that accepts the same request style they already use. If your store makes them learn a new integration, many will skip it.

A compatible endpoint lowers that barrier. A reseller points their existing software at your domain, enters their credentials, and imports your service list. They don't need a developer or a custom integration project.

What lives at /api/index.php

A single, predictable URL is the front door for your API traffic. Resellers set it as the API address in their own system, and the same endpoint handles the everyday actions a reseller panel needs:

• Account information: confirm the connection works and show the reseller's wallet balance.
• Service listing: return your IMEI and server services with names, delivery times and the reseller's pricing.
• Order placement: accept a new order and return a reference.
• Order status: let the reseller's system check progress and read the reply when it is ready.

Because the request and response structure follows the Fusion convention, existing integrations tend to need little more than a new URL and credentials. You can read how GSMSS approaches this on our Fusion API page.

Wallet billing keeps API orders clean

An API without sound billing quickly turns into a support burden. Wallet billing solves this by making every API order draw from a prepaid balance. The flow is simple:

1. The reseller tops up their wallet in your store.
2. Each order placed through the API debits the price of that service.
3. If the balance is too low, the order is declined before it reaches a supplier.
4. Every debit and credit is recorded against the reseller's account for reconciliation.

This gives you predictable cash flow and gives your resellers a clear ledger. Nobody has to chase invoices for a batch of 300 API orders.

Reseller-specific pricing and access

An API shouldn't mean one price for everyone. A good setup lets you assign reseller groups with their own pricing, so a high-volume partner sees different rates from a new sign-up. Each reseller should also get their own API access key, which you can regenerate or revoke if it is exposed or the relationship ends. Handling this inside the admin panel, rather than editing files, is what makes it manageable at scale.

Handling failures honestly

Orders in this business pass through third-party suppliers, and no supplier succeeds every time. Your API should report outcomes faithfully: pending, in process, completed or rejected, with the supplier's reply text passed through. When a rejected order is refunded to the wallet automatically, resellers can trust your numbers. That trust is worth more than any promise about results, and it is one reason resellers stay with a supplier.

White-label hosting: the API on your own domain

Your resellers should connect to your brand, not to a platform vendor. With white-label hosting, the endpoint sits on your domain, such as yourstore.com/api/index.php. GSMSS hosts and maintains the store for you, so you don't manage servers, patches or uptime yourself. You get a branded IMEI unlock store and a reseller-ready API without running infrastructure.

How this compares with DHRU Fusion

DHRU Fusion is the best-known name in this space, and it earned that position. It is a self-installed script, which suits teams comfortable with their own hosting, updates and security. The trade-off is that the server work stays with you.

GSMSS is a managed alternative. You get the same style of API compatibility, plus hosting, upkeep and a modern admin and user panel. If you want a closer look, our DHRU Fusion alternative page sets out what to evaluate. Which one fits depends on whether you would rather own the stack or have it run for you.

A quick checklist before you open your API

• Test the endpoint with a real reseller panel, not just a manual request.
• Confirm the service list shows the right prices per reseller group.
• Check that low-balance orders are declined cleanly.
• Make sure rejected orders refund to the wallet.
• Decide how you will issue, rotate and revoke API keys.
• Write short onboarding notes for new resellers: URL, credentials, wallet top-up steps.

Moving over from another platform

If you already run a store elsewhere, you don't have to rebuild everything. GSMSS offers free migration, and the details are on our migration page. Plans start from $20/month, and there is a 90-day free trial, so you can test the API with a few friendly resellers before rolling it out. Current plan details are in the pricing section.

The takeaway

A Fusion-compatible reseller API turns your store from a retail site into a supplier other shops can build on. With a single endpoint at /api/index.php, wallet billing, per-reseller pricing and hosting handled for you, you can grow wholesale volume without growing your workload.