- Is domainreseller/php-dna a Laravel package with a service provider and facade?
- No. It is a framework-agnostic PHP client for the DomainNameApi reseller API, so there is no ServiceProvider, facade, publishable config file, or queue and event integration. In a Laravel application you install it with Composer and wrap it behind your own registrar contract, treating the vendor namespace as an implementation detail that only one adapter class touches.
- How do I install domainreseller/php-dna in a Laravel application?
- Install it with composer require domainreseller/php-dna and commit the resulting lock file so deploys are reproducible. If you download from GitHub, use the tagged release archive from the Releases page rather than the green Code then Download ZIP button, which gives you the raw development branch. Store the Reseller ID and API key, or the legacy username and password, in a config file backed by environment variables or a secret manager rather than in version control.
- What PHP version and extensions does domainreseller/php-dna require?
- The library requires PHP 7.4 or higher, with PHP 8.1 recommended, which fits Laravel 10 through 12 comfortably. The SOAPClient extension must be enabled for legacy SOAP mode, and the cURL extension must be enabled for REST mode. Check these extensions in your deployment image, since missing them surfaces as a runtime error rather than an install-time failure.
- Does the library support both SOAP and REST, and how does it choose which API to use?
- Yes, it supports both the legacy SOAP API and the modern REST API. You pass both credentials into the same two constructor parameters and the library auto-detects the API: a Reseller ID in UUID format plus an API key routes to REST, while legacy username and password credentials route to SOAP. Plan for the REST path if your panel credentials are current, and keep a test that asserts which transport your configuration actually selects.
- Should I inject the DomainNameApi client directly into controllers or wrap it?
- Wrap it. Define your own RegistrarContract covering register, renew, transfer, contacts, DNS, lock and privacy, then implement a single DomainNameApiAdapter that is the only class allowed to reference the vendor namespace. Bind that adapter as a singleton in a service provider with configured credentials and HTTP options, and add an architecture test that fails if the vendor namespace leaks into other namespaces. This keeps retries, idempotency, state machines and reconciliation as your code, and makes swapping registrars a canary rather than a rewrite.
- How do I test Laravel code that talks to DomainNameApi?
- There is no documented sandbox or shipped test suite to rely on, so treat live API calls as unsuitable for your test suite. Build a FakeRegistrar that implements your contract and is backed by recorded response payloads, then bind it in the container during tests. Also assert in an architecture test that only your adapter namespace may reference the vendor classes, so the fake cannot silently drift from the real implementation.
- Does domainreseller/php-dna throw typed exceptions or return error codes?
- The documentation does not guarantee typed exceptions, and reseller SDKs of this shape commonly return arrays with embedded error codes instead. Assume silent failure is the default until you verify otherwise. Wrap every call in your adapter, inspect the response payload, and throw your own domain-specific exceptions so failures surface in logs, jobs and alerts rather than disappearing into a returned array.
- Is domainreseller/php-dna safe to depend on in production?
- Be aware of the risk profile: a single author, low star count, no known dependents, and no visible CI, test suite or security policy. The Apache-2.0 license gives you an explicit patent grant and fork rights, which materially reduces the bus-factor problem. Pin a specific release tag, verify its date against the repository tags before locking it in, review the code for credential or contact PII logging, and assume you may need to maintain a fork.
- How does the library handle asynchronous operations like transfers and pending registrations?
- Expect registrations and transfers to be asynchronous on the registrar side, moving from pending to active or failed, and do not assume the client ships order-status polling helpers. Store a local domains and domain_orders mirror for reconciliation and reporting, and treat DomainNameApi as the system of record for state. Drive polling and state transitions from queued jobs you own, since the library provides transport, not lifecycle semantics.
- Can I retry a failed register or renew call without double-charging?
- There is no evidence of idempotency key support, so a blind retry after a timeout risks a duplicate registration attempt and a double charge. Route all write operations through queued jobs with a per-registrar concurrency cap, starting around five, and reconcile ambiguous results against your local mirror before retrying. Configure explicit timeouts and treat unknown outcomes as pending-verification rather than failure, resolving them with a status lookup before the next write.