AiVikings.ai supports reseller and sub-customer domain workflows through its API/MCP platform. Your application must map each client to the intended customer and registration contact before placing an order. A reseller account is not a reason to register every client's domain with the reseller's own legal details.
How it works
Store an internal tenant identifier, the associated AiVikings.ai customer reference and the intended contact reference. Resolve those values on the server after authenticating the application user. Never accept a browser-supplied customer identifier as proof that the user may order for that customer.
The registration request accepts a customer_id and contact-related inputs. The API checks customer access in the authenticated context. An illustrative request shape is:
{
"domain":"your-client-approved-domain.tld",
"period_years":1,
"customer_id":"your-authorized-customer-id",
"contact_handle":"your-verified-contact-handle",
"allow_premium":false
}
These are placeholders, not real customer identifiers. Validate the contact and quote before sending the paid request. Consult the operation reference for the registration route and the current request contract.
Can reseller clients buy through my own platform?
Your platform can present domain candidates and pricing, obtain the client's approval and call AiVikings.ai from its trusted backend. The client can stay in your workflow without using a registrar checkout for every order. Your platform remains responsible for its own customer experience, billing relationship, access controls and operational records.
Do not expose the reseller's bearer token in the storefront. A browser should call your backend, where tenant access and purchase authority are checked. Your backend then performs the authorized registrar operation and returns the relevant result to that client.
Who should be the registrant?
Use the party intended to hold the domain rights under the customer agreement and applicable registration rules. That identity should be explicit before automation begins. A project's billing contact, agency project manager and domain registrant can be different people or organizations. Do not let a default contact silently decide ownership for every client.
How should billing and renewals be tracked?
Keep the client's commercial order separate from the registrar operation. Record the exact domain, term, currency, quote, customer mapping and confirmed result. For renewals, identify who authorizes continued holding and who maintains funding. A paid client invoice is not proof that the domain renewal completed at the registrar.
What happens when a client leaves?
Prepare a handover record containing domain identifiers, expiry dates, contact responsibility, nameservers and the authoritative DNS provider. Follow the supported account or transfer process for the required handover. Do not promise a particular account-push capability merely because the platform supports sub-customers.
When this is not the right fit
A reseller API does not supply a complete tax, invoicing or customer support system for your business. WHMCS operators should evaluate the WHMCS module before building an order lifecycle from scratch.
Continue with reseller platform, authentication, and MSP handover.
Questions people ask
Can reseller clients buy domains through my platform?
Yes. Build the client experience around server-side AiVikings.ai operations and verified customer mappings.
Should the storefront contain the registrar token?
No. Keep credentials in a trusted backend and validate tenant access there.
Does sub-customer support decide legal ownership?
No. The intended registrant and contact responsibility must be explicitly established.
Should WHMCS users build a custom integration first?
Review the AiVikings.ai WHMCS registrar module first; it may already cover the required order workflow.