Build an AI API Reseller Site You Can Monetize—with Branded Page and API Domains

Build an AI API reseller site that can earn revenue from eligible customer purchases—then make the customer journey feel consistent with separate branded domains for the portal and the API.

Ace Data Cloud’s White Label API Platform lets you operate a developer-facing AI site under your own brand, with a service catalog, pricing, documentation, customer accounts, and API delivery. The underlying AI services are maintained by the platform, so you can focus on the offer, customer acquisition, onboarding, and support rather than building an entire portal and backend from scratch.

This tutorial focuses on one engineering handoff that is easy to get wrong: using one hostname for pages people browse and another for requests their applications send.

Scope note: a basic system-domain site can be created in a few minutes when your name and prefix are ready. DNS propagation, HTTPS issuance, production acceptance, and revenue are separate steps and are not promised to finish in five minutes.

Why two branded domains matter

A developer customer interacts with two different surfaces:

Surface	Example	Used for
Page domain	platform.example.com	Homepage, service catalog, docs, login, and console
API domain	api.example.com	The Base URL used by application code

Using distinct names makes the contract easier to understand. The browser-facing site explains what you sell; the API hostname is the programmatic entry point.

A custom API domain is a branded entry point. It is not a separately delivered gateway, independent tenant identity system, or automatic credential-isolation mechanism. Authentication and billing still follow the platform’s unified system. Hiding a catalog item is also not a substitute for credential scope controls.

1. Create the portal before touching DNS

Sign in with the webmaster account and open Site Management. Create a site with a short prefix and the external brand name.

The prefix accepts 3–32 lowercase letters, numbers, or hyphens. Do not include the full system domain in that field. After creation, add the site name, description, logo, and favicon, then open the system-assigned URL in an incognito window.

Check these paths before adding custom domains:

• homepage;
• service catalog and current prices;
• developer documentation;
• registration and login;
• customer-support entry.

This order gives you a known-good baseline. If the custom hostname later fails, you can separate a portal configuration problem from a DNS or certificate problem.

2. Prepare records without copying historical targets

In Site Management → Manage → Custom Domain, find the separate Page Domain and API Domain sections. For each section:

1. enter the complete hostname without https:// or a path;
2. click the bind action for that section;
3. copy the CNAME target shown by the current console;
4. create the DNS record with your provider;
5. return to the console and refresh or verify status;
6. wait for both domain and HTTPS status to become ready.

A planning sheet can look like this:

brand: Example AI
page_domain:
  hostname: platform.example.com
  type: CNAME
  target: COPY_FROM_CURRENT_PAGE_DOMAIN_SECTION
api_domain:
  hostname: api.example.com
  type: CNAME
  target: COPY_FROM_CURRENT_API_DOMAIN_SECTION

Do not publish the actual target as reusable documentation. The two targets may differ, and old screenshots or another tenant’s values are not authoritative. If an A, AAAA, or CNAME record already uses the hostname, confirm its purpose before changing anything; choosing an unused subdomain is safer than deleting a production record.

DNS visibility and certificate issuance are separate states, so avoid promising a fixed completion time.

3. Accept the page domain like a new customer

Open the page hostname in an incognito window. Verify the homepage, catalog, docs, support link, and login flow. Open a nested documentation page and refresh it to catch routing that works only through client-side navigation.

Record a compact acceptance result:

Page host: platform.example.com
HTTPS: ready
Homepage/brand: pass
Catalog/pricing: pass
Docs deep-link refresh: pass
Login and return URL: pass
Checked at: 2026-11-08T10:00:00Z

The title, logo, and favicon should match the intended brand. A polished domain that lands on an error page is not a successful launch.

4. Accept the API domain without leaking a Key

After HTTPS is ready, inspect the platform’s current default documentation and code view. Confirm that examples use the branded API Base URL rather than an old public hostname.

For documentation, use a placeholder:

export AI_API_KEY="replace-with-customer-owned-key"
export AI_BASE_URL="https://api.example.com"

curl --fail-with-body \
  -H "Authorization: Bearer ${AI_API_KEY}" \
  "${AI_BASE_URL}/DOCUMENTED_LOW_RISK_PATH"

Replace the path with one copied from the current service documentation. Do not invent a universal endpoint, paste a real Key into an article, or assume every request is free. Before running any paid operation, check its current price.

For a real customer acceptance test, use that customer’s own account and Key. Confirm one minimal documented request and the corresponding usage or billing record in the customer console. For asynchronous tasks, query the original task ID instead of resubmitting a paid request when the first result is unclear.

5. Connect the technical launch to revenue correctly

A branded domain improves trust and makes promotion easier, but it does not itself generate commission. Revenue depends on customer attribution and qualifying purchases under the current distribution rules.

In Distribution Settings, understand the difference between a default relationship and a mandatory relationship before saving. Test attribution with a genuinely new account entering through the intended domain. An existing shared-system account does not become a new customer merely by revisiting your site.

Also keep three records separate:

1. Displayed selling price — affected by site-wide or service-specific markup, with service-specific settings taking precedence.
2. Usage record — evidence that the customer received and used the service.
3. Distribution record — evidence that an eligible completed purchase produced revenue under current rules.

Markup is not automatically equal to your income, and commission is not credited once per API call. Refunds, risk controls, order status, attribution, and settlement rules can change the final amount. This is a business opportunity, not a promise of fixed or automatic earnings.

A practical launch definition

You are ready to promote the site when:

• the system URL still provides a fallback;
• the page domain renders the full customer journey;
• the API domain has valid HTTPS;
• current docs and code samples show the intended Base URL;
• a customer-owned Key completes a minimal documented test;
• pricing, attribution, order, usage, and distribution records are understood separately;
• no credentials or customer information appear in public screenshots or support tickets.

Start with a small catalog you can explain and support. Then publish tutorials aimed at a specific customer task, bring new customers through the branded portal, and earn from eligible purchases according to the current rules.

Continue building

• Create a White Label API Platform from scratch
• Bind page and API domains
• Understand customer attribution and revenue
• Open API Site Management

This article is an AI-assisted adaptation of Ace Data Cloud’s current public documentation, reviewed to avoid credentials, customer data, and income guarantees.