A branded AI API portal is not complete when the homepage renders. It is complete when a developer can register, obtain a credential, make one controlled request, and reconcile that request with a usage record—without sending a secret to your support team.
This tutorial presents a narrow, repeatable onboarding runbook for an Ace Data Cloud White Label API Platform. It is aimed at operators serving developers who will integrate AI into applications or workflows. If your customers mainly want browser-based creative tools, the White Label Studio is the more appropriate product.
Disclosure: Ace Data Cloud is the product discussed here, and this article is part of its white-label education and promotion program. It was prepared with AI assistance from current public documentation, then reorganized as an independent technical tutorial. I did not create a tenant, change DNS, make a purchase, or generate earnings while preparing it.
Define the handoff contract first
Before inviting a customer, prepare four values:
| Item | Example placeholder | Why it matters |
|---|---|---|
| Portal URL | https://portal.example.com | Registration, login, docs, and account UI |
| API base URL | https://api.example.com | Destination used by the customer's program |
| Service/model name | PUBLIC_MODEL_NAME | Exact public identifier required by the service docs |
| Documentation URL | https://portal.example.com/docs/service | The single integration path being tested |
Do not treat the portal URL and API base URL as interchangeable. One is for people; the other is for requests. If you configure custom domains, obtain the required CNAME targets from your own console rather than copying values from a tutorial or another tenant.
For the first handoff, select one service and one supported integration style—native API, an OpenAI-compatible protocol, or MCP, as applicable. Testing every protocol at once creates an unnecessarily large failure surface.
Step 1: Send an onboarding message that does not contain secrets
A useful customer message is short and operational:
Open https://portal.example.com and register or sign in with your own account. Open the console, enable the target service, and create your own API key. Base URL: https://api.example.com Service/model: PUBLIC_MODEL_NAME Docs: https://portal.example.com/docs/service Start with the smallest documented request. Do not send your full API key in a support ticket. If something fails, send the timestamp, status code, request path, and a non-sensitive request ID. This separates customer support from credential custody. The operator supplies endpoints, product guidance, pricing context, and troubleshooting; the customer owns the account and key.
Step 2: Make the customer create a scoped key
After signing in through your portal, the customer should navigate to the console's applications area and open credential management for the chosen application. Ace Data Cloud's public onboarding guide identifies /console/applications and /console/credentials as the relevant paths, while noting that the service-specific flow can vary.
Use a recognizable credential name such as onboarding-staging. Where the UI offers them, set:
- a usage limit appropriate for the test;
- an expiration date;
- an allowed-API scope restricted to the service being evaluated.
Treat each customer, project, and environment as a separate security boundary. A production backend and a staging script should not share a key. Store credentials in a server-side secret manager or protected environment configuration—not browser JavaScript, a repository, chat, or screenshots.
A subtle but important distinction: hiding a service from the visible catalog is merchandising, not authorization. If a key must not call a service, enforce that through the credential's actual API restrictions and verify the behavior.
Step 3: Run one minimum-cost acceptance request
Use the smallest request from the selected service's documentation. Keep values as environment variables and let the service-specific documentation define the endpoint and payload:
export AI_BASE_URL="https://api.example.com" export AI_API_KEY="replace-with-the-customer-owned-key" curl --fail-with-body \ -H "Authorization: Bearer ${AI_API_KEY}" \ -H "Content-Type: application/json" \ "${AI_BASE_URL}/DOCUMENTED_PATH" \ --data @minimal-request.json This is deliberately a template, not a fictional SDK or universal endpoint. Copy the real path, authentication format, model name, and JSON body from the chosen service's documentation. Confirm the displayed price before submitting a paid request, and avoid bulk, long-video, or other high-cost jobs during onboarding.
For asynchronous media APIs, an accepted job is not a completed result. Save the task identifier and follow the documented status flow until the job reaches a terminal state.
Step 4: Reconcile delivery with usage
A successful response is only half of acceptance. In the customer's console, locate the corresponding usage entry and compare:
- request time;
- service or model;
- recorded consumption;
- balance change;
- request or task identifier, where available.
Your acceptance criterion should be explicit:
One successful minimal call plus one matching usage record.
If the two sides do not match, capture the timestamp, path, status code, and safe request ID. Never ask the customer to paste the full authorization header.
Step 5: Close the test safely
If the credential was created only for onboarding, the customer should disable or delete it after confirming that no application depends on it. A low-risk follow-up request can verify that the retired key is rejected. Production credentials should then be created separately with the narrowest practical scope and an intentional rotation policy.
Where monetization actually enters the workflow
A portal can present your brand, selected services, channel pricing, documentation, and support path. That makes it possible to operate an AI service business, but registration and API traffic do not automatically equal revenue.
Ace Data Cloud's public rules distinguish customer attribution from earnings. Attribution depends on the applicable invitation relationship; earnings depend on qualifying completed purchase orders and current distribution rules, with order status, refunds, risk controls, and settlement adjustments potentially affecting the final record. A configured markup changes the channel price but should not be presented as guaranteed profit. Commission is not generated independently for every API call.
Therefore, keep two audit trails separate:
- technical delivery: credential, request, result, and usage record;
- commercial settlement: customer attribution, completed purchase, and distribution record.
That separation makes support easier and prevents a common operational mistake: inferring revenue from a frontend price or an API usage event.
Launch checklist
Before sending the first real customer:
- [ ] Portal and API URLs are clearly labeled and reachable.
- [ ] One service has current pricing and complete documentation.
- [ ] The customer uses their own account and credential.
- [ ] The test key has an appropriate limit, expiry, and API scope.
- [ ] A minimal call produces a matching usage record.
- [ ] Support instructions exclude full keys and authorization headers.
- [ ] Commercial claims describe opportunity, not guaranteed income.
A white-label portal is a branded developer experience, not a separately delivered gateway or an isolated tenant identity system. Its practical value comes from reducing the work needed to organize discovery, documentation, pricing, credentials, and support—while leaving customer acquisition and day-to-day operations with the site owner.
