Apps and access applications
This console centralizes apps, applications, messages and developer accounts. The internal administration platform reviews API integration; official administrators in the aggregate platform review hosted merchants. Applicants submit and view results here in both cases.
1. Create an app
One developer account can manage multiple apps. Choose by deployment mode:
- Create API app: enter the app name, company/team, contact details and business website. Apply for access after creation.
- Create hosted merchant: enter the merchant name, company/team and contact details and submit an access application. The site is available only after approval and provisioning.
The list shows integration modes and access states. Open details from the app name, management action or access status. Modes cannot be changed after creation.
2. Apply for access
API apps require a server outbound IP, full callback URL and application notes. Each app accepts one IPv4 or IPv6 address, without a domain, port or subnet. Hosted merchants do not supply these settings; the platform manages them.
Edit app details updates the current basic information. Each application stores a submission snapshot; later edits do not change earlier applications or active integration settings. Once provisioned, hosted site display names are managed in the merchant dashboard.
3. Review and history
Inbox provides application feedback and links to the relevant app. Mark all as read applies to all messages for the account, regardless of filters.
App details show submission, review and first activation times. Hosted merchants also show provisioning attempts. Approval does not mean provisioning is complete. Historical applications retain their submitted details; app details show the current active configuration.
After rejection, complete a new application rather than resubmitting the old form. Previous applications and review notes are retained.
4. API credentials and verification
Approval exposes the endpoint, code and secret for that app. The code is generated independently and cannot be edited: code_ followed by 20 random hexadecimal characters. New secrets contain 32 ASCII characters.
Credentials supports showing, hiding and copying the secret. Regenerate secret requires confirmation and affects only the current app, without changing code. Old secrets and tokens become invalid when runtime services refresh configuration; the result is recorded in Inbox. Keep secrets only on your server, never in frontend code, logs or repositories.
The platform manages endpoints for this deployment and sends change notifications. With the kit, update the endpoint, code and secret under Game integration settings, then test and save. For custom systems, follow Custom integration.
5. Hosted sites and dashboards
Once provisioning completes, app details show the player URL and merchant dashboard entry. The owner uses the developer identity; staff accounts and permissions are created in the merchant dashboard. The platform manages game integration credentials.
Ongoing maintenance
For API apps, open Callback & IP allowlist → Edit integration settings in the app details. Saving does not change application history, code or secret and does not require another application. Changes take effect when runtime services refresh configuration. Deploy the new callback first: queued retries will also use it. Only one outbound IP is allowed for this deployment.
Select your email in the console header to change your developer password. Enter the current password and confirm a new password of 10–72 bytes. All devices and related merchant dashboards must sign in again. API code and secret remain unchanged.