A reseller API lets another panel or application buy from your catalog without manually using the order form. The reseller authenticates as an account, selects a service and submits the fields that service requires.
Provider APIs source services upstream; reseller APIs sell your catalog downstream. This guide covers the second relationship. The reseller API overview explains ExcelPanel’s commercial workflow.
The account comes before the request
An API key identifies an account with its own balance, prices and permissions. Treat it like a password. Public code examples should use placeholders, and support logs should redact credentials.
Use the panel’s current documentation for the endpoint, authentication format and supported actions. Similar-looking SMM APIs can differ. Copying a request from another platform is not a compatibility test.
Read the catalog in the reseller’s context
The reseller needs the service identifier, rate unit, quantity limits, order type and required inputs. A name is not a complete specification. Check whether a rate is per 1,000 units and whether customer-specific pricing applies.
The public storefront rate does not necessarily establish the reseller’s charge. Read the custom pricing guide before testing an integration.
Submit a controlled first order
Choose a low-value test meeting the service minimum. Submit the documented service ID, quantity and required link or extra fields. Save the returned panel order identifier; do not substitute a supplier identifier unless the documentation requires it.
Record the time, action, non-secret inputs and response. Those details let both businesses investigate an exception without disclosing the key. Validate inputs before submission so malformed links do not become avoidable support work.
Separate acceptance from completion
An accepted request is not evidence that the supplier finished the service. Use supported status actions and handle each status according to its documented meaning. A timeout is also different from a rejection.
Investigate an uncertain submission before resending it. Your integration needs a reconciliation process so a retry does not purchase the same service twice. Preserve the local record and response rather than assuming an empty screen means no order exists.
Follow balances and eligibility independently
The reseller account funds purchases from your panel. Your provider balance funds upstream purchases. Merchant confirmation is a third workflow, not an order API response.
Refill and cancellation actions depend on the service, eligibility and supplier support. A request may still require approval. Keep the returned identifier or explanation for support follow-up.
Agree the operating contract
- Supported actions, service types and input fields.
- Effective prices and account currency.
- Error handling and uncertain-submission reconciliation.
- Responsibility for enquiries and catalog changes.
- How exposed credentials are replaced.
Test catalog, balance, order and status workflows before extending access. Businesses that need a storefront as well as connectivity should compare child panels.
