Laravel Rdap Laravel Package

Product Decisions This Supports

• Feature go/no-go: domain & IP intelligence. This package covers the read-only lookup layer for a family of candidate features: domain expiry monitoring and renewal reminders, domain portfolio dashboards, brand/typosquat triage inputs, domain-ownership verification during onboarding or KYC, and IP enrichment for fraud, abuse, or analytics pipelines. Deciding whether any of these are worth building is now a days-level question rather than a sprint-level one.
• Build vs buy, at the data-access layer. The alternative to this package is not "buy" — it is hand-rolling a WHOIS scraper that HTML-parses per-registrar output and breaks constantly. RDAP is the structured-JSON successor to WHOIS, and this package wraps it with the boring parts (TLD→server discovery from IANA, caching, retries, typed responses) already solved. That is roughly 1–2 engineer-weeks of undifferentiated work removed from the roadmap.
• Roadmap sequencing and scope cutting. Because cost-to-first-value is low, this supports shipping a thin, internal-facing slice first (e.g. an expiry alert job) and deferring the full "domain intelligence" surface. It also lets you descope anything requiring global TLD coverage, historical WHOIS records, or registrar contacts — none of which this provides.
• Coverage as a product requirement. RDAP does not support every TLD, and the package exposes domainIsSupported() precisely so you can design around it. This forces an explicit PM decision: is "supports .com/.net/.dev but not .be" acceptable for launch, or is global coverage a launch gate that requires a paid provider?
• Freshness and cost as tunable product behavior. Caching of TLD server lists (default one week) and retry/timeout budgets (default 5s × 3 attempts) are config knobs that map directly to user-facing latency and to how hard you hit public registry endpoints. These are product trade-offs, not just ops settings — they determine whether a lookup can sit inline in a request or must be queued.
• Risk acceptance on data quality. RDAP responses are subject to GDPR redaction, registry inconsistency, and flakiness (hence the built-in retries). Accepting this package means accepting a "best-effort registry data" product claim rather than an authoritative one.

When to Consider This Package

Consider it when most of the following hold:

• You are on a Laravel/PHP application and want a first-party-feeling facade rather than wiring HTTP clients yourself.
• The use case is read-only lookup of a bounded set of attributes: registration/expiration/last-changed dates, domain status flags (hasStatus()), and raw RDAP properties via get() with dot notation.
• Volumes are low to moderate and user- or job-triggered — onboarding checks, nightly expiry scans, on-demand back-office lookups. Caching and retries make this viable at that scale, not at bulk scale.
• TLD coverage gaps are tolerable, or you can degrade gracefully using domainIsSupported(). Internal tools and English/gTLD-heavy audiences usually qualify.
• You want the option to point at a custom RDAP server (dnsServer:) for a specific registry, private endpoint, or test double.
• Time-to-market matters more than data guarantees, and you are willing to encapsulate the integration so it can be swapped later.

Look elsewhere when any of these are true:

• Global TLD coverage is a hard requirement. No fallback to WHOIS is included; unsupported TLDs simply return null. You need a commercial WHOIS/RDAP aggregator (WhoisXML, DomainTools, IPinfo, Team Cymru for IP) alongside or instead of this.
• You need historical records. RDAP is current-state only. Domain-sale history, ownership-change timelines, or "was this ever registered" questions are out of scope.
• You need bulk or high-throughput enrichment. Public registry endpoints rate-limit and throttle; the package's retry mechanism is a reliability feature, not a throughput strategy. Millions of rows is a job-queue-and-vendor problem.
• You need SLA, support contracts, or indemnification. This is MIT-licensed open source with a modest footprint (~72 stars, no known dependents). Spatie's maintenance track record is good and releases are current (Laravel 12 support, PHP 8.4 fixes), but there is no commercial backstop.
• You need write operations or registrar functions. Registration, transfer, renewal — not this.
• You need registrar contact data at scale. GDPR redaction means contact fields are often absent; treat any contact-based feature as unreliable.
• You are not on Laravel, or you need a language-agnostic service boundary — use a plain RDAP client or a thin internal service instead.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed library from a well-known PHP vendor that lets us query public domain-registration and IP-registry data in structured form. It replaces a brittle scraping approach and removes roughly one to two engineer-weeks of plumbing. It unblocks a class of features — expiry monitoring, domain verification, IP enrichment — at very low cost and low commitment. The trade-off is coverage: not every country-code TLD is supported and the data is best-effort, not authoritative. Recommendation: adopt it for internal-facing and low-stakes read-only use, behind our own abstraction layer so we can swap in a paid provider if coverage becomes a customer-facing requirement.

To engineering: composer require spatie/laravel-rdap, publish the config, and you get a Rdap facade with domain(), ip(), dns(), and domainIsSupported(). Responses are typed (DomainResponse, IpResponse) with Carbon-returning date helpers, get() for arbitrary properties with dot notation, and hasStatus() for domain status enums. TLD→server resolution is pulled from IANA's list and cached for a week by default; per-query timeout, retry count, and backoff are configurable globally and overridable per call. Errors are normalized: RdapRequestTimedOut and InvalidRdapResponse both implement RdapException, so one catch handles both. Custom registry endpoints via dnsServer: make it testable.

Risks and mitigations to state up front: TLD gaps (mitigate with feature gating on domainIsSupported()); upstream registry flakiness and rate limits (mitigate by queueing lookups rather than doing them inline, and by respecting the cache); GDPR-redacted contact fields (mitigate by not promising contact-level data); single-maintainer-ish dependency (mitigate by wrapping it in our own interface, which we'd want anyway for swapping to a commercial provider).

Ask: approve a timeboxed spike — one engineer, a few days — to validate coverage against our actual top-N domains and confirm latency fits the intended UX. Decision to scale up follows the spike, not precedes it.