Customer Registration, API Key, and API Delivery

This article is the Customer Registration and API Delivery Guide for the White Label API Platform, not a third revenue model. It walks through the registration, application creation, API Key generation, minimal calls, usage records, and credential deactivation for a brand new test customer, completing the delivery acceptance before going live.

Completion Effect

Customers register a shared identity system account from the white label page domain, create applications and API Keys in their account, and call through a custom API domain; request, billing, and credential status can be verified in the customer console.

Preparation Before Starting

  • A test customer who has never registered before;
  • An activated page domain and API domain;
  • A low-cost, side-effect-free test interface;
  • Clearly defined customer support scope and credential management rules;
  • Not using the Key of the webmaster or other customers;
  • Screenshots in this article do not create Keys or send billing requests; actual acceptance should be executed by the business side in a controlled account.

Step 1: Register from the White Label Entrance

  1. Open a brand new incognito window;
  2. Visit the white label page domain;
  3. Click on register;
  4. Complete registration using a test email or phone number that has never been registered;
  5. After confirming authentication, return to the original white label domain;
  6. Record the entrance domain, account identifier, and exact time.

The white label entrance creates a shared identity system account, not an independent user database for this Site. Existing accounts can log in to multiple sites and cannot be used to verify "first registration attribution."

Step 2: Customer Creates Independent Applications and Keys

Log into the customer’s console:

  1. Open application management;
  2. Create an application specifically for acceptance;
  3. Create an independent API Key;
  4. Only store the Key in a secure location;
  5. Do not place the Key in the web front end, public documents, screenshots, tickets, or group chats.

Each customer, project, and environment should use an independent Key. Webmasters should not distribute their main Key to customers, nor should they promise in documentation that they can directly deactivate customer credentials across accounts.

Step 3: Deliver Four Pieces of Information

Base URL: Currently activated custom API domain
API Key: Created and managed by the customer
Service / Model: Public name currently delivered
Docs: Development documentation under the current white label page domain

Copy the minimal request from the documentation, verify the Host, path, model/service name, required parameters, and asynchronous polling instructions. Do not use high-resolution, long videos, or batch tasks for the first acceptance.

Step 4: Execute Minimal Call and Verify Records

  1. Use the test customer’s Key to initiate a low-cost request;
  2. Record the time, path, status code, and publicly identifiable request;
  3. Find the corresponding usage record in the customer console;
  4. Verify service, consumption, and balance changes;
  5. Verify the billing units specified in the documentation;
  6. Do not record the complete request header or Key in customer service materials.

Step 5: Validate Delivery Methods Separately

Method What the Customer Needs Acceptance Focus
Native API Base URL, Key, API documentation Path, parameters, return structure, asynchronous polling
Compatible Protocol base_url, Key, public model name Can the SDK return results as per documentation
MCP / Integration Installation method, environment variables, tool instructions Tool discovery, authentication, timeout, and quota

These methods can reuse the same customer account, application, and billing system, not three independent tenant ledgers.

Step 6: Customer Deactivates Test Key

  1. Deactivate or delete the acceptance Key on the test customer’s own credential page;
  2. Resend the same request;
  3. Confirm the old Key is rejected;
  4. When creating a new Key, confirm the old Key will not be restored;
  5. Write the rotation, leak response, and customer exit process into internal operation instructions.

Current Boundaries

  • White label registration uses a shared identity system;
  • Custom API domains will not automatically restrict Keys to the current Site;
  • Service/document hiding is not a calling permission;
  • Webmasters cannot set mandatory service scopes or manage Keys across accounts solely based on directory configuration;
  • When true scope limitation is needed, the platform's credential/API scope capabilities should be used and accepted separately.

Success Indicators

  • A brand new customer registers from the white label entrance and correctly returns;
  • The customer creates and manages an independent Key in their account;
  • The minimal call to the custom API domain is successful;
  • Usage records, quotas, and billing are consistent;
  • Documentation, public model/service names, and Base URL are consistent;
  • The old Key cannot continue to be used after deactivation;
  • The customer understands the support scope and credential security responsibilities.

Frequently Asked Questions

Copying Code Still Uses Public API Domain

Confirm that the API domain status is activated, then reload the Site and documentation. Do not manually replace in each example to cover up that the domain configuration has not taken effect.

Call Successful but Usage Records Temporarily Not Visible

Record the time, path, status code, and publicly identifiable request; wait briefly and check again; if still missing, contact support. Do not provide the complete Key.

Key Can Call Services Not Displayed in the Directory

Directory visibility is not permission isolation. When forced scope is needed, use actual credentials/API authorization capabilities, rather than relying on Site menus or service lists.

Next Article

Continue reading Customer Attribution, Markup, and Distribution Revenue to verify first registration relationships and settlement criteria.