Building a useful AI API service involves more than exposing endpoints. Your customers also need somewhere to find the right capability, understand the purchase flow, read integration instructions, and reach support.
This walkthrough covers setting up a branded developer portal with Ace Data Cloud's white-label API Platform. It focuses on the decisions that make the portal useful for customers: catalogue, documentation, branding, domains, and a verifiable first-use path.
Disclosure: this is a product guide from the Ace Data Cloud team. The examples use our public YourBrand demo; they are configuration examples, not customer revenue claims.
Watch the setup walkthrough
This 91-second walkthrough shows the configuration screens for branding, services, pricing, documentation, and domains. English and Simplified Chinese captions are available in the player settings.
Watch the full API Platform setup demo on YouTube.
1. Start with the customer and their first task
Choose a concrete audience before building a broad catalogue. A software agency integrating image generation into client applications needs a different starting point from a community building music workflows.
For a first version, write down:
- Who will use the portal?
- Which task should they be able to complete first?
- Which services do you understand well enough to support?
- Where should questions about accounts, orders, or integration go?
This gives you a practical way to decide what belongs on the homepage and which documentation should appear first.
2. Create the portal and configure the brand
In the Platform console, open Site Management, choose Create, and enter a site name and subdomain prefix. The current prefix format is 3–32 lowercase letters, digits, or hyphens; it must begin and end with a letter or digit and cannot contain consecutive hyphens.
Start with the system-provided address. In the site's management screen, configure the name, description, logo, and favicon. Check the site in a private browser window so you see what a customer sees.
The step-by-step API site guide includes the current forms and screenshots.
3. Organise services and documentation around that first task
Use the service and documentation settings to organise the portal. Adjust display names, descriptions, ordering, and the visible catalogue where those options are available.
For each service you feature, a customer should be able to answer:
- What does it do?
- Where are the usage and pricing details?
- How do I get from this page to the integration instructions?
- What should I provide to support if a request fails?
A visible catalogue entry is a discovery surface. Hiding an entry is a display decision; it should not be treated as revoking underlying API access.
You can inspect the public YourBrand API demo before choosing a catalogue structure.
4. Treat pricing, customer attribution, and earnings as separate checks
A site can use site-wide pricing overrides and supported service-specific overrides. A service-specific setting takes priority; it is not another percentage to stack on top of the site-wide override.
Customer purchase price and the operator's final earnings are separate records. Earnings depend on eligible orders, customer attribution, applicable distribution rules, and adjustments such as refunds. Example markup values in a demo are not a quote or a promise of profit.
Before promoting a commercial offer, confirm the current customer attribution and earnings rules and verify the relevant order records.
The white-label product uses a shared account, balance, and package system. Plan your customer explanation around that actual model; branding does not create a separate user database or an independently isolated billing stack.
5. Add domains after the system address works
The website domain and API domain serve different customer needs. Configure the ones your product requires, then follow the current DNS and certificate instructions.
Allow time for DNS and certificate processing. A successful site creation does not mean a new custom domain is already active.
After domain setup, repeat the same customer checks you performed on the system address: homepage, catalogue, documentation, sign-in, and the published integration route.
6. Validate the full customer journey
Before inviting a wider audience, walk through the launch sequence:
| Step | Evidence to keep |
|---|---|
| Open the site as a visitor | Correct brand, clear primary service, working support link |
| Follow the documentation | A customer can locate the next integration step |
| Check registration attribution | The actual new account is attributed as intended |
| Make an intentional small purchase or request | Correct order, credit, and usage records where applicable |
| Inspect the operator's records | Eligible earnings follow the current rules |
Real generation and payment checks can incur charges, so select an appropriate small test and inspect the actual records. A successful API request and an earnings entry are different outcomes; one is not proof of the other.
If a launch check fails, use the API support-ticket template to record the failing step, time, sanitized error, and non-secret request or task ID before contacting support. The companion guide also covers asynchronous timeouts and checking credentials, redirect URLs, and verbose logs before sharing evidence.
Once the first path works, keep the initial catalogue focused and add services based on customer demand. Maintain a clear support route and review usage, repeat purchases, and support effort before expanding the offering.
Explore the product
If your customers want to integrate AI into an application, begin with the API Platform creation guide.
If they want to create directly in a browser, the Studio white-label guide covers the other product route.
For standard product or account questions, use the official support page.
Top comments (0)