Your apps. Separate environments.

Multiple applications, Live and Sandbox

Use the Live and Sandbox tabs in Developers, then Add application for each game or website. Names must be unique within your account and environment. The same game can have separate Live and Sandbox applications. Each application is independently reviewed and has its own client ID, API key, callback list, creator approvals and earnings attribution. Rotating, suspending or revoking one application does not affect another.

Register up to 10 exact callback URLs, one per line. Live URLs require HTTPS. Sandbox additionally allows HTTP on localhost and 127.0.0.1. Wildcards, URL fragments, embedded credentials and duplicate callbacks are rejected. Choose one approved callback in the copyable starter configuration; authorization requests must match it exactly. Callback changes use the existing admin review workflow.

Both tabs use the displayed BMM origin. The client ID determines the Connect environment; do not add an environment override to API requests. Approval and token exchange work for both environments on the same deployment. Creators see the environment during consent and can revoke either environment in Share → Connected apps.

The real creator response includes environment: "live" or "sandbox". Earnings queries return only payments attributed to that exact application and environment, never another game's or environment's records. profile_url and support_url are null when the connection environment does not match the deployment's payment environment. In particular, Sandbox applications on a live-payment deployment cannot open live checkout, even if someone constructs a URL using their attribution reference. Sandbox connection testing is available immediately after approval; simulated payments still require a deployment configured with Bachs sandbox credentials. Empty sandbox earnings are not populated with fictional payment records.

Update your website or callback

Approved, active applications can use Developers → Edit website & callback to submit new URLs for admin review. Your existing URLs, API key and creator connections remain active while the request is pending. Only one URL request can be pending at a time.

Approval updates the existing application, keeping that application’s ID and credentials. The approved callback list replaces the previous list for new authorization requests; update your platform configuration and restart any in-progress connection attempts. Your copyable starter configuration reflects the approved callback. Rejection keeps the existing URLs and lets you submit another request. HTTPS and exact callback matching still apply; localhost HTTP is allowed only in sandbox.

Archive an application

In Developers, select the application's Live or Sandbox tab, choose the application, and select Archive application. Confirm the displayed name and environment. Archiving immediately disables its credentials, revokes its OAuth and hosted creator connections, invalidates unfinished connection attempts and stops its attributed support links. Other applications are unaffected.

Archived applications remain visible as inactive rows with an Archived badge. Use the application dropdown and confirm Unarchive application to restore the previous approval state. Prior admin suspensions remain in force. Older archives without saved suspension state remain disabled until an admin reviews them. Creators must reconnect; revoked permissions, old support links and unfinished attempts are never restored.

Existing payments and earnings attribution records remain intact; archiving does not change creator balances or withdrawals. The application, credentials and connection records are retained for history. If another active application uses the same name in the same environment, archive that application before restoring the original.