From first customer to a complete reseller business.

1. Choose the right API and account

Begin by registering accurate contact information and choosing your own password. Open the confirmation email and explicitly confirm it; merely opening a verification URL does not activate an account. Do not create another registration if you lose the confirmation message. Retry the existing registration or contact support. Device and IP reuse can block registration, including on a shared office network. Support can review a legitimate conflict; repeatedly changing details is not a supported workaround.

1. Verify your reseller email and sign in to the portal.
2. Create a dedicated integration key with the reseller permission.
3. Read GET /account, GET /products and GET /models.
4. Run a non-billable sandbox check before enabling purchases.
5. Fund your wholesale wallet only when you choose to issue paid packages.
6. Save each customer’s returned issued-record ID alongside your own order ID.

The public GET https://myapi.world/api discovery endpoint identifies the API version, documentation and customer API base. Other reseller management operations require authentication. The examples below use relative paths under the reseller API base unless a complete URL is shown.

2. Authentication and safe key handling

Send Authorization: Bearer YOUR_RESELLER_API_KEY on every authenticated request. An active reseller System Token is accepted, but a separate User API Key with the reseller permission is recommended for integrations. A regular customer account does not become a reseller merely by creating a key, and a dashboard browser session token is not a management API credential.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/account' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Accept: application/json'

The account response includes account and reseller objects. Check the returned wholesale balance, account status, current margin, minimum top-up, preferences and trial inventory rather than keeping those values permanently in your application. Money values ending in Usd are decimal USD amounts; values ending in Cents are integer cents. Use decimal arithmetic for money.

Key administration belongs to the portal

In the portal’s API Keys section, you can create, replace or revoke a separate key and configure its supported expiration and IP restrictions. Key replacement invalidates the previous value, so update every application using it. Limited reseller keys cannot administer arbitrary keys, change account passwords, grant themselves administrator rights, or operate on another reseller’s customers. Do not share your reseller credential with end customers.

Keep integration secrets on your backend, outside source control and browser code. The documentation does not request, save or insert a real key. Avoid tokens in query strings: they can be retained in browser history, access logs and referral headers. Customer detail, setup and migration responses can contain a customer System Token; protect these responses as credentials and send them only through an authorized delivery channel.

A request is checked against the active account, key permission, expiry and applicable IP allowlist. Reseller ownership is enforced again on individual customer, domain, notification and funding-order operations. An inaccessible ID does not grant access even if it was obtained from a URL or another account.

3. Discover models, products and current prices

GET /models returns public model IDs, display names, capability labels, supported endpoint paths, reasoning effort choices and client availability. It excludes private routing configuration. Use each returned ID exactly; display labels are not interchangeable with API IDs. A model may require a supported coding client even when it appears in the catalogue. Discovery does not override that requirement or create an entitlement.

GET /products is the authoritative list of products your reseller integration can currently issue. It includes the reseller price and capacity where applicable. Never assume that a package shown in an old example is still on sale. Read the catalogue before presenting a choice and handle a later unavailable-product error: availability can change between your catalogue request and purchase.

GET /catalogue adds the broader customer-facing model, membership, subscriber Unlimited and fixed-credit catalogue. Its products list contains enabled public plans and their billing options; availability still depends on the selected customer’s eligibility and current stock. Its creditPackages describe retail credit packs. These retail prices are different from the wholesale issue prices returned by /products.

Memberships and subscriber Unlimited packages retain the customer checkout and eligibility workflow. Listing them does not authorize a reseller to manufacture a paid membership or bypass a subscriber requirement. Direct customers can choose the current plan at Subscribe; use their own account for checkout and billing consent.

4. Fund the reseller wallet with PayPal or crypto

Enrollment is free. Wholesale wallet funding is a separate, explicit purchase. Create a checkout with POST /wallet/checkout, passing amountUsd and paymentMethod. Choose paypal or paymento; PayPal is the default. The currently enforced deposit range is $50–$5,000, with the minimum also reported in GET /account. This minimum applies to optional wallet funding, not registration.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/wallet/checkout' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"amountUsd":"50.00","paymentMethod":"paypal"}'

Store the returned provider order identifier and redirect the payer to the returned checkoutUrl. Do not construct a payment URL from an email address or calculate an on-chain destination yourself. Checkout creation does not mean payment succeeded. Do not issue a paid customer package until verified funds are available in your reseller wallet.

PayPal approval and confirmation

The payer reviews and approves the amount on PayPal. Then send the same saved order ID to POST /wallet/paypal/confirm. The service verifies ownership, expected amount, currency and receiver before crediting. It only captures an order that the payer already approved. A return to your page alone is not proof of payment.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/wallet/paypal/confirm' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"orderId":"YOUR_PAYPAL_ORDER_ID"}'

The response includes paymentMethod, orderId, credited and alreadyCredited. A repeated confirmation cannot add the same deposit twice. If approval is pending, retain the order and let the payer finish. If a response is lost, confirm that same order instead of creating and paying a replacement.

Paymento cryptocurrency confirmation

Create the same checkout using "paymentMethod":"paymento". Send exactly the asset, network and amount displayed on the secure checkout before its deadline. Blockchain confirmation can take time. Read the latest stored status with GET /wallet/paymento/orders/{order_id}; request a fresh provider verification with POST /wallet/paymento/confirm and {"orderId":"YOUR_CRYPTO_ORDER_ID"}.

The status GET is read-only and does not settle funds. Confirmation returns the sanitized order plus credited, alreadyCredited and cashWallet indicators. A pending result is not a failure and must not trigger another payment automatically. If an amount is routed to Cash Wallet under the underpayment rules, it is not necessarily wholesale balance; check cashWallet, the order’s status and the current account balance before provisioning.

Wholesale deposits represent actual paid dollars. Product-specific crypto discounts do not increase a wholesale deposit or reduce the amount required for it. Paymento credentials belong to the service and are never supplied to reseller integrations. Provider callbacks are verified by the service; your application must not fabricate callback payloads or treat a client-supplied success flag as settlement.

POST /wallet/confirm remains only for valid historical card receipts and is deprecated for new integrations. Use the explicit PayPal or Paymento confirmation routes for all new deposits.

5. Create, deliver and top up customer accounts

Create a customer

Choose an available packageId from GET /products. Submit it to POST /customers with a stable Idempotency-Key for that business order. Supply the recipient’s accurate email. Optional fields include a preferred username, first and last name, a spending-alert percentage and an owned active custom-domain ID. Keep personal information in the JSON body, never in a reusable idempotency key.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/customers' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Idempotency-Key: customer-order-10001' \
  -H 'Content-Type: application/json' \
  -d '{"packageId":"credit-10","email":"customer@example.com", 
       "firstName":"Alex","lastName":"Example","spendingAlertPercent":80}'

This example package ID is illustrative: first confirm it appears in the live issue catalogue. Paid issuance checks and debits your wholesale balance under the normal transaction locks. The response contains the issued customer and delivery information according to the package type. Keep the issued-record ID for subsequent operations; it is not the recipient’s underlying user ID. Trial invitation responses intentionally differ from fully active paid-account delivery.

Find and retrieve customers

GET /customers?q=alex&limit=50&offset=0 searches only your issued customers by username, email or package. The response includes customers, total, limit and offset. The effective page size is capped at 200. List entries omit the System Token. GET /customers/{issued_id} returns one owned customer and its token for authorized delivery. Treat these credential-bearing responses as private.

Top up an existing customer

Use POST /customers/{issued_id}/topups with an eligible paid package and a new business-operation idempotency key. This adds the purchased benefit to the existing account and preserves its System Token. Trial packages cannot be used for top-ups. A recipient ID from another reseller is inaccessible.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/customers/123/topups' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Idempotency-Key: customer-topup-10002' \
  -H 'Content-Type: application/json' \
  -d '{"packageId":"credit-25"}'

Deliver setup instructions

GET /customers/{issued_id}/setup?platform=all returns separate instructions and executable scripts, plus API URLs and supported setup models. You may request one platform by the exact key returned in the scripts object. The optional custom-domain query parameter is domain_id. It must identify your own active domain. Display the explanatory instructions outside the copyable script block so customers can paste the script as provided.

For a migration, download /customers/{issued_id}/migration-bundle.zip. It includes sensitive customer setup credentials and must not be published. For branded email delivery, POST /customers/{issued_id}/welcome-email accepts an optional customDomainId and requires an active owned domain. This operation sends a real message; call it only when you intend to contact that customer, not as a connectivity test.

6. Assign the ten starter trials

An eligible newly verified reseller receives ten starter assignments. Check the account’s reseller.starterTrials object for available, assigned and total. The live /products entry identifies the full-suite trial by reseller-starter-trial. Existing inventory is not refilled merely because the enrollment flow changed.

Assign a starter trial through the same customer-creation endpoint with the trial package ID and a valid recipient email. The recipient receives an invitation, verifies their email and chooses their password. Do not provide a temporary password for this flow or count a sent invitation as an activated account.

{
  "packageId": "reseller-starter-trial",
  "email": "invited-customer@example.com"
}

Each eligible trial includes $15 Credit Wallet, 30 minutes of All Models Unlimited, one day of Lite and one day of VIP. Lite and VIP begin when the recipient activates. Unlimited begins on the first coding pass within that trial day, rather than issuance or login. Wallet credit is separate from the included allowance. The recipient does not need a card or payment to activate the trial.

Only one eligible trial may be assigned per recipient and device. Trials cannot be stacked on the reseller’s own account. The inventory is consumed once and protected against concurrent requests and duplicate retries. If email delivery requires review, preserve the existing assignment and contact support instead of creating another account. Paid membership and supplier-backed benefits keep their separate eligibility rules.

7. Usage, statements, notifications and support

GET /customers/{issued_id}/usage returns the owned customer’s usage ledger. Supported filters include q, model, date_from, date_to, limit and offset. Use the query names exactly as shown in the reference. The JSON page size is capped at 1,000; /usage.csv exports up to 1,000 matching rows. Usage responses do not contain prompt or response text.

GET /transactions reports reseller wallet activity, including funding, purchases, customer top-ups, commissions and adjustments. Filter by transaction_type, search and date range. JSON and CSV/PDF exports are bounded to 5,000 records per request. For longer histories, page through JSON or narrow the date range. A transaction is the record of an event; do not infer a new grant from a historical label.

Use PUT /preferences for wholesale low-balance notifications and PUT /customers/{issued_id}/spending-alert for a customer threshold. The latter accepts spendingAlertPercent from 1 to 100 and disabled. These controls configure notifications, not a new credit allocation. Read GET /notifications and acknowledge an owned notification with its acknowledgement endpoint.

Diagnose without charging a coding pass

POST /customers/{issued_id}/connectivity checks authentication and model discovery using that customer’s existing token without generating a billable model response. GET /customers/{issued_id}/support-diagnostics produces a redacted support bundle without raw credentials or conversation content. These checks establish connectivity, not successful generation for every model or proof of available allowance.

The sandbox endpoints return deterministic, non-billable Responses, Chat Completions and Messages structures. They do not call a model, execute tools, emulate a real streaming tool round trip or validate provider capacity. Expect X-MyAPI-Sandbox: true, X-MyAPI-Billable: false and zero usage.

curl --fail-with-body 'https://myapi.world/api/reseller/v1/sandbox/responses' \
  -H "Authorization: Bearer $RESELLER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"sandbox-echo","input":"Check response parsing"}'

Legacy challenge endpoints report only an already-enrolled account’s eligibility and claim window; their presence does not enroll a new reseller or promise an available promotion. Withdrawal endpoints apply only to eligible commission Cash Wallet funds and manual payout rules. Wholesale deposits and promotional package balances are not interchangeable with withdrawable funds. Read the account response and handle an ineligible request normally.

8. Offer a branded customer experience

You can manage up to five owned custom domains. Create a domain with POST /domains, supplying hostname, brandName, supportEmail and optional branding. The response supplies the exact DNS records needed for ownership and routing. Do not replace unrelated DNS records or assume a domain is active immediately after creation.

1. Register your hostname and accurate support contact.
2. Read /domains/{domain_id}/dns-guide, optionally selecting your DNS provider.
3. Set the returned A and TXT records at that provider.
4. Request verification with POST /domains/{domain_id}/verify.
5. Wait until the returned status indicates active HTTPS before delivering customer setup for that domain.

Changing a hostname resets verification and HTTPS activation. The logo upload accepts PNG, JPEG or WebP with a 2 MB decoded limit. Use the documented JSON schema rather than arbitrary file paths. Domain maintenance settings display a customer-facing notice; they do not stop coding API traffic. Analytics provide bounded daily aggregates without conversation content. Branded documentation downloads remain owner-authorized.

Deleting a domain is an operational action and may interrupt customers using its URL. Coordinate a migration first and distribute fresh setup links where necessary. Domain ownership does not grant access to administrator functionality or customers belonging to another reseller.

9. Connect customers to the coding API

The reseller management API is separate from inference. Use the recipient’s System Token or appropriately scoped customer User API Key at https://api.myapi.world/v1, or at the active domain returned in that customer’s setup. A reseller credential does not impersonate a customer for generation. Calls follow the recipient’s current wallet, membership, Unlimited availability, client requirements and normal rate limits.

curl --no-buffer --fail-with-body 'https://api.myapi.world/v1/responses' \
  -H "Authorization: Bearer $CUSTOMER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"gpt-6.1-sol","input":"Reply with OK","stream":true,
       "reasoning":{"effort":"xhigh"}}'

This is a real, normally billed generation request. Test deliberately using an authorized account; sandbox success alone is not equivalent. For Responses streaming, parse server-sent events incrementally and check for completion or error events before marking the pass successful. HTTP 200 is not sufficient if the stream ends early. Keep tool call IDs and corresponding results intact when continuing a conversation. Execute client tools only with the customer’s permissions.

curl --fail-with-body 'https://api.myapi.world/v1/messages' \
  -H "Authorization: Bearer $CUSTOMER_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -d '{"model":"claude-opus-5-5","max_tokens":64,
       "messages":[{"role":"user","content":"Reply with OK"}]}'

Choose a model from the customer’s live catalogue rather than relying on example names forever. Request the needed permission when creating a customer User API Key: model discovery, Responses, Messages and Chat Completions are separate permissions. Additional client account and wallet routes are described in the customer API schema and managed setup instructions. Browser account operations require the customer’s own authenticated dashboard session. These do not become cross-customer reseller powers.

10. Idempotency, errors and production integration

Use an Idempotency-Key for every POST /customers and POST /customers/{issued_id}/topups. Valid keys contain 8–200 characters, start with a letter or digit, and otherwise contain letters, digits, dots, colons, slashes, underscores or hyphens. Generate one stable value per business operation and save it before the request is sent.

Retry the same operation with the same body and key after a network failure. A matching replay returns the original result; reusing the key with different details conflicts. Do not generate a new key simply because the first response was lost. For payment confirmation, retain and retry the same provider order ID. Checkout creation is not a generic idempotent purchase endpoint: prevent double clicks in your interface and retain an existing returned checkout.

General error responses use a detail field, which can be a string or validation details. Treat it as data and escape it in your interface. Do not depend on exact English wording for business logic. Use status codes, explicit result flags and your saved order state. Never log authorization headers, customer tokens, passwords, full setup scripts, private payment information or verification links.

Bound requests and polling. Request only the page size and date range needed, avoid overlapping polls, and stop once an order reaches a final state. A stored crypto status can lag the provider; a deliberate confirmation request refreshes it. Request IDs, endpoint, timestamp, HTTP status and your own opaque operation ID are useful support information without disclosing credentials.

Before releasing an integration, verify owner isolation, a rejected insufficient-permission key, deterministic sandbox parsing, handling of pending payments, duplicate retry behavior in an isolated environment and secure delivery of customer credentials. Do not charge a real payment, create trial grants or send welcome messages just to exercise a button.

Generated from the installed API

Complete reseller endpoint reference

The reference below reflects the registered reseller operations, including current provider-specific funding endpoints. Field names and required status come from the installed schema. /api is public discovery; all /api/reseller/v1/… operations require an active reseller credential. The schema intentionally excludes administrator routes and browser-session account controls.

48 operations

No endpoints match. Try a shorter term.