The FOSSBilling adapter's native test-mode switch does not create a Domain Nexus sandbox. In this release, enabling that switch causes the connector to refuse the request before contacting the upstream API. Plan testing around a separately authorised environment and clearly identified credentials.
IN THIS ARTICLE
01 Prepare a controlled test
- Confirm the installed FOSSBilling and connector versions. Check the native registrar contract and relevant release notes.
- Obtain an approved staging API endpoint and account if we have supplied one for your test. A production URL with a local sandbox tick is still not a staging service.
- Configure the selected authentication method. Standard authentication uses an API username/email and API-key environment variable; advanced HMAC uses a key ID and signing-secret variable.
- Make the secret available to both web PHP and scheduled workers, with appropriate source-address permissions.
- Start with availability and an owned-domain read before any charged lifecycle action.
02 Check native behaviour
Exercise the supported domain registration, transfer, renewal, contact, nameserver, lock and privacy paths on the authorised test environment. Check pending outcomes and normal synchronisation, not just an HTTP connection.
Where no staging registrar is available, use read-only checks and agree a specific controlled live purchase before testing paid operations. Treat that purchase as real. The adapter does not silently translate local test mode into a safe upstream transaction.
Registry deletion remains disabled by default. DNS and forwarding use the reseller portal; this adapter does not add an unimplemented native FOSSBilling DNS tab.
Common questions
Why does enabling sandbox return an error immediately?
The adapter explicitly refuses that unsupported assumption and sends no upstream request. Use a separately provisioned environment instead.
Can I use a sample API key from a package?
The published ZIP contains no reusable reseller secret. Issue or obtain a credential for the intended environment.
Does a generated package guarantee compatibility with my 0.x release?
No. FOSSBilling's pre-1.0 contracts can change. Verify the installed release's registrar interfaces and actual workflows before enabling customer orders.
What should be recorded after testing?
Keep the platform and connector versions, environment identity, operation references and actual outcomes. Exclude secrets and unnecessary customer data from the acceptance record.
Related articles
- Install the Nabtech Domain Nexus registrar adapter in FOSSBilling
- Diagnose API permission errors using the profile and capability endpoints
- Roll out a new connector release while retaining a working previous package
- Replace an API key's scopes and network allowlist without locking out workers
- Recover a FOSSBilling renewal without reusing an updated expiry as a new order