Domrobot Laravel Package

Technical Evaluation

Architecture fit

The package is a thin, framework-agnostic RPC client for INWX's Domrobot API (JSON-RPC/XML-RPC). It is not a Laravel package: no service provider, no facade, no publishable config, no queue or event hooks. That is a fit, not a defect — it slots in cleanly as a low-level adapter behind our own domain/DNS port interface, keeping vendor specifics out of domain code. It should never be injected directly into controllers or jobs; wrap it.

Integration feasibility

Low effort. composer require inwx/domrobot, PHP with ext-curl and ext-json, credentials in env, and an endpoint switch between production and the OTE sandbox. A spike against OTE is achievable in a day. The real work is not adoption — it is building the thin layer around it (typed results, retries, audit logging) that the library deliberately omits.

Technical risk

• Raw cURL transport. The client bypasses Laravel's HTTP client, so Http::fake(), retry middleware, request logging, and tracing do not apply. Testability requires either a wrapper interface with a fake implementation or network-level stubbing.
• Stateful sessions. Login/cookie/session handling is procedural; long-running workers and multi-tenant use need careful session scoping or re-auth logic.
• Array-shaped responses. Numeric code / resData / msg payloads with no typed DTOs mean every consumer re-implements error interpretation; inconsistent handling is the most likely source of production bugs.
• 2FA/TAN flow. Accounts with TAN enabled need an explicit unlock path — easy to miss until it fails in production.
• Destructive operations. Deletes, transfers, and contact updates are not idempotent and have no dry-run. Guardrails must live in our wrapper.
• Supply chain. 46 stars and zero dependents means no third-party vetting, but also negligible fan-out risk. MIT license is clean.

Key questions

1. Which API mode does the current release default to — JSON-RPC or XML-RPC — and is XML-RPC deprecated by INWX?
2. What is the declared PHP support matrix, and does it cover our target runtime?
3. Is there a test suite and CI, or is the repo essentially a single-maintainer wrapper?
4. What are INWX's published rate limits, and how does the client behave on 429/5xx?
5. Does the client expose TAN/unlock, or must we call it manually?
6. Is OTE at functional parity with production for the operations we need?

Integration Approach

Stack fit

Works on any Laravel 10+/PHP 8.1+ stack as a Composer dependency. Bind it as a singleton in a dedicated DomainServiceProvider, publish a config/domrobot.php for endpoint, credentials, language, and timeouts, and expose a Domrobot facade only if it improves ergonomics. Everything else goes through our own RegistrarClient / DnsProvider interface.

Migration path

If DNS or domains are currently managed manually or via raw cURL scripts, migrate one operation class at a time — start read-only (domain.info, nameserver.info, domain.check) to validate auth, session, and response parsing in OTE, then enable writes. Do not attempt a parallel-run cutover for registration or transfer flows; the API is not idempotent enough for dual-write.

Compatibility

• Pin to a specific minor version; the API surface is stable but the project is small and SemVer discipline should be verified rather than assumed.
• Confirm the endpoint switch covers OTE; sandbox credentials are separate.
• Check for cURL option conflicts if we set global defaults (timeouts, proxies) elsewhere in the app.
• Account-level TAN settings are an environment property, not a code property — document them per environment.

Sequencing

1. OTE spike: auth, session reuse, one read call, one write call, error mapping. (~2–3 days)
2. Build the adapter: typed result objects, error taxonomy, structured logging with correlation IDs, retry policy on transient failures only.
3. Ship read-only DNS/domain visibility into internal tooling.
4. Enable DNS record automation (lowest blast radius, easiest rollback).
5. Enable registration/transfer behind an approval step and audit trail.
6. Decommission legacy scripts.

Operational Impact

Maintenance

Small surface area, so low ongoing cost. The recent release timestamp is reassuring, but the burden shifts to us: the wrapper, error taxonomy, and tests are ours to own. Budget for an annual review of upstream changes and a vendor API deprecation watch (XML-RPC sunset is the most plausible breaking event).

Support

No commercial support; GitHub issues and INWX's own API documentation are the escalation path. Internal knowledge will concentrate in one or two engineers — mitigate with a runbook covering credentials, TAN, OTE, and the error-code table. INWX's registrar support is responsive for account issues but will not debug our client code.

Scaling

Sufficient for typical registrar volumes (hundreds to low thousands of domains), but constrained by synchronous blocking HTTP, per-account API rate limits, and the absence of batching beyond API-level bulk calls. Bulk DNS operations across many zones must be chunked and dispatched to queued jobs with backoff; do not attempt them in a web request. Session reuse helps, but concurrent workers need independent sessions or serialized access.

Failure modes

• Session expiry mid-batch → partial application with no rollback.
• TAN challenge triggered unexpectedly on a scheduled job → silent failure until the next run.
• Destructive calls succeeding but the response parse failing → duplicate or orphaned operations on retry.
• Rate-limit throttling during a zone migration → incomplete record sets.
• Upstream API change with no client release → hard failure requiring a hotfix.

Each needs an explicit detection and recovery story before write paths go live.

Ramp-up

Fast. A mid-level PHP engineer with RPC experience is productive in one to two days; the library is small enough to read end to end. The genuine learning curve is INWX's domain semantics and error codes, not the code — plan for access to a domain-literate engineer and a live OTE account during onboarding.