Disclosure: This article was prepared for Ace Data Cloud’s white-label promotion program and was AI-assisted, then reorganized and checked against the public documentation linked below. It is a technical guide, not a claim of personal revenue or independent testing.
A branded AI API portal is useful only when a developer can move from “I found a service” to “my first request appears in usage records” without receiving credentials over chat. That onboarding path matters more than a polished homepage: it defines who owns each secret, which URL belongs in code, and how support can investigate failures safely.
This guide describes that complete handoff for an API portal created with Ace Data Cloud. It assumes the portal already exists. The goal is not to create an independent gateway or tenant identity system; the white-label portal provides branded presentation, service discovery, pricing, documentation, and customer access within the platform’s supported model.
1. Prepare four deliverables before inviting a customer
Do not start onboarding with a generic homepage link. Prepare a small integration packet:
| Item | What the customer needs |
|---|---|
| Page domain | Where they register or sign in |
| API base URL | Where their application sends requests |
| Service/model name | The public identifier shown in the service documentation |
| Documentation URL | The exact integration page, not merely the homepage |
Use placeholders in templates, for example:
Page: https://portal.example.com API base URL: https://api.example.com Service/model: <PUBLIC_SERVICE_NAME> Guide: https://portal.example.com/docs/<SERVICE> A page domain and API domain have different jobs. Never tell a customer to send API requests to the documentation site. If you have not activated a custom API domain, use the address currently shown in your own console and documentation; do not copy a CNAME value from somebody else’s tutorial.
Before launch, open the portal in an incognito window and verify that a visitor can find the service, its current price, authentication instructions, required parameters, errors, and—where relevant—the submit-task and query-result steps for asynchronous APIs.
2. Make the catalog support the onboarding route
A broad catalog can create more support work than value. Start with a few services your team understands. In Site Management → Manage, configure Services and Pricing and Document Management separately.
Service coverage can change visibility, display title, summary, ordering, or a service-specific markup. A service-specific markup takes precedence over the site-wide ratio; it is not added twice. Leaving that field blank inherits the overall setting, while zero means no markup for that service.
Documentation visibility is a separate concern. Hiding a service does not automatically hide its documentation, and hiding a directory entry is not an authorization control. Put the beginner path first:
- What the service does
- How to obtain a customer-owned key
- One minimal request
- Full parameters and response fields
- Errors, limits, and asynchronous status handling
Keep public model names, package names, SDK class names, and environment variables unchanged. Branding belongs around the integration contract, not inside identifiers that code must use.
3. Require customer-owned accounts and keys
Ask the customer to register or sign in from your page domain. After authentication, confirm that the browser returns to that domain. Ace Data Cloud’s documentation describes a shared identity system, so a white-label site should not be presented as supplying a separate user database or an independently isolated tenant identity layer.
The customer then opens Console → Applications, chooses the relevant application, and enters Manage Keys or Keys. From the credentials page, they create a key with a recognizable name such as staging-first-call.
Where the interface supports them, select appropriate usage limits, expiration, and allowed APIs. “No restrictions” should be treated literally; it must not be confused with a service hidden from the catalog.
Use separate keys per customer, project, and environment. Store keys in server-side secret configuration, never in frontend JavaScript, a public repository, screenshots, support tickets, or onboarding messages. The site operator should not ask customers to send the full key.
A safe environment example is:
export AI_API_BASE_URL="https://api.example.com" export AI_API_KEY="<CUSTOMER_OWNED_KEY>" This is intentionally not a fabricated SDK example. The actual request path, headers, model name, and payload must come from the selected service’s current documentation.
4. Define acceptance as a request plus a record
For the first test, choose a low-cost, small request instead of a batch, music, or long-video job. Copy the minimal example from the service documentation and replace only the base URL, customer key, and required parameters.
A successful HTTP response alone is not enough. Open the customer’s usage records and match the request by time, service, consumption, and balance movement. For asynchronous APIs, receiving a task identifier means “accepted,” not “completed”; continue polling exactly as the documentation specifies.
A practical acceptance criterion is:
- one successful completed request; and
- one corresponding usage record.
If it fails, collect the timestamp, path, status code, and public request identifier. Never paste complete request headers into support channels because they can contain credentials. Delete or deactivate a temporary acceptance key only after confirming that no application still depends on it.
5. Separate monetization settings from revenue claims
A portal can support a commercial operation through branded discovery, configured prices, customer purchases, and applicable distribution rules. But markup is a selling-price input—not a guaranteed payout.
Customer attribution and revenue are also separate. A default relationship may consider existing invitation information, while a mandatory relationship can override promotional links, cookies, and defaults. Use the latter only when that business rule is intentional.
Revenue is determined from qualifying completed purchases and the current distribution rules, subject to order state, refunds, risk controls, settlement timing, and other adjustments. It is not a commission emitted for every API call, and registration or usage alone does not establish earnings. Reconcile customer orders, quota/usage records, and site-owner distribution records rather than estimating income from the displayed markup.
Launch checklist
- [ ] Page and API URLs are clearly distinguished
- [ ] A focused service is visible and priced correctly
- [ ] Authentication, errors, limits, and async handling remain documented
- [ ] Customer creates and stores their own scoped key
- [ ] Minimal request completes and appears in usage records
- [ ] Attribution and purchase records are checked separately
- [ ] No credential or customer identity appears in public screenshots
The result is a portal that is easier to operate: customers get a repeatable integration path, support gets non-secret diagnostic data, and commercial outcomes remain tied to verifiable purchases rather than promotional promises.
