Build an AI API Site You Can Monetize: Portal Setup and Customer Key Onboarding

A white-label AI API business is not only an endpoint. A usable developer product also needs a service catalog, pricing, documentation, authentication, customer credentials, support, and a path from registration to a verified first request.

This tutorial presents one practical workflow: create a branded Ace Data Cloud API portal, configure its minimum viable customer experience, and onboard a developer with their own API key. It is an operating pattern, not a claim that the portal is an independent gateway or a separate tenant identity system.

Disclosure: Ace Data Cloud is the product discussed here, and this article supports its white-label program. It is an independently reorganized tutorial based on public documentation, prepared with AI assistance. I did not create a live customer site or perform a paid transaction for this article.

1. Define the product before opening the console

Start with a narrow offer rather than exposing every available AI capability. For example:

APIs for application teams building chat, image, and video workflows.

Prepare these items:

• a public brand name;
• a short site prefix;
• a one-sentence description;
• a logo and square favicon;
• one service you can document and support well;
• a support channel, terms, and privacy policy.

This constraint matters. A smaller catalog with clear pricing and documentation is easier for a customer to evaluate than a large catalog with ambiguous onboarding.

Use the site-owner account to create the portal. Do not use a customer test account, because administrative ownership and customer testing should remain separate.

2. Create the API developer portal

Open Site Management, select Create, and enter the prefix and site name.

The prefix must contain 3–32 lowercase letters, numbers, or hyphens. It cannot begin or end with a hyphen, and consecutive hyphens are not allowed. The console appends .platform.acedata.cloud, so enter only the prefix—not a complete hostname.

After creation, open Manage → Site Settings and configure the site name, description, logo, and favicon. The system-assigned origin is read-only. A custom address belongs in the Custom Domain workspace rather than the origin field.

The portal organizes operational settings into workspaces. A sensible implementation order is:

1. Site Settings and Authentication Settings
2. Navigation Menu and Homepage Banner
3. Services and Pricing and Documentation Management
4. Distribution Settings
5. Custom Domain
6. Terms and Privacy and site statistics

Do not bind a production domain first. Visit the system URL in a private browser window and verify that the homepage, catalog, documentation, and login entry are reachable. This separates portal configuration problems from later DNS or HTTPS problems.

3. Build a customer-ready service entry

For the first service, the portal should answer four questions without requiring a sales call:

• What does the service do?
• What is the current customer price?
• Which public service or model identifier does code use?
• Where is the smallest working integration example?

Keep marketing names separate from identifiers required by the API documentation. Also distinguish the page domain, where customers browse and sign in, from the API base URL, where software sends requests.

A safe onboarding configuration uses placeholders:

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

Do not publish a real key in documentation, source control, browser JavaScript, screenshots, or support messages. The exact request shape should come from the selected service's official documentation; do not invent a universal SDK or assume that native APIs, OpenAI-compatible protocols, and MCP use the same setup.

4. Onboard each customer with an independent key

Send the customer to your page domain to register or sign in. White-label sites use a shared identity system; they do not create an independent user database for every portal. An existing account can sign in, while testing first-customer attribution requires a genuinely new account.

The customer then opens Console → Applications, selects the relevant application, and goes to Manage Credentials or Credentials. They create a clearly named key such as staging-onboarding, optionally applying the limits, expiration, and allowed APIs offered by the credential form.

Use one key per customer, project, and environment where practical. The customer should store it in server-side secret management and should not send the full value to the site operator. Hiding a service from the catalog is not an authorization control; actual key restrictions must be configured and tested separately.

Give the customer this four-part handoff:

Have them execute one low-cost request copied from the service documentation. Success is not merely receiving a task ID: asynchronous media services may require polling until a terminal result. Finally, match the request to a usage record by time, service, and consumption. A successful response plus a corresponding usage record is the minimum useful acceptance test.

5. Treat monetization as an operating system, not a promise

A branded portal creates a place to acquire and serve customers, but registration or API usage alone does not guarantee revenue. Customer attribution and earnings are separate concepts: attribution follows the configured invitation/distribution rules, while earnings depend on eligible completed purchases and the current distribution rules.

Channel markup changes the displayed sale price; it does not mean the entire difference is automatically the operator's income. Refunds, risk controls, order status, settlement timing, and upstream distribution relationships can affect the final record. Earnings come from qualifying purchases—not a separate commission on every API call.

Therefore, reconcile three records after a customer makes an authorized purchase: the completed customer order, the customer's balance/usage, and the operator's distribution record. Avoid fixed-income claims, and verify current rules in the console before quoting percentages.

Launch checklist

• System URL works in a private window.
• Brand, catalog, prices, docs, support, terms, and privacy are visible.
• Page and API domains are labeled correctly.
• A new customer can register and obtain their own key.
• A minimal request produces a matching usage record.
• Attribution and completed purchases are reconciled separately from calls.

This sequence turns “we expose AI models” into a supportable developer product while keeping the platform's identity, credential, and commercial boundaries explicit.

Sources

• Build your own white-label API platform
• API Platform: from zero to one
• Customer registration, API keys, and API delivery
• Customer attribution, markup, and distribution earnings