Ratsit Bundle Laravel Package

Technical Evaluation

Architecture fit — the headline is a framework-layer mismatch, not a code-quality problem. jongotlin/ratsit-bundle is a Symfony bundle: a Bundle subclass, a DependencyInjection extension, and a YAML configuration tree loaded from config/packages/*.yaml. Laravel has no bundle concept, no compiler passes, and no YAML config tree, so the package cannot boot in a Laravel application as shipped. Its only Laravel-relevant asset is the underlying jongotlin/ratsit client, which is plain PHP and installable via Composer. The TPM framing that follows from this: we are not evaluating a package, we are evaluating a data vendor, and the package's contribution (DI wiring, config schema) is roughly 100 lines we would write ourselves in a day.

Integration feasibility — moderate, contingent on the underlying client's coupling and transport hygiene. Direct library consumption is a routine Composer install. The feasibility questions worth 30 minutes of engineering time are: does the core pull symfony/* transitively (http-client, serializer, options-resolver)? Symfony components coexist with illuminate/* but are a recurring source of version-pin conflicts and a maintenance tax. Equally important: does the client accept an injected PSR-18/PSR-17 HTTP client and PSR-3 logger, or does it instantiate its own transport? If the latter, we cannot apply our own retry, timeout, circuit-breaker, or redaction policy, which is disqualifying for a PII-bearing call path.

Technical risk — concentrated in maturity, vendor dependency, and legal basis, in that ascending order of severity.

• Maturity: zero stars, zero dependents, single maintainer, pre-1.0, no SECURITY.md, no CVE history in either direction, no production references. "No known vulnerabilities" and "never examined" are different statements, and only the second applies here.
• Vendor dependency: the strategic exposure is Ratsit.se — its pricing, rate limits, terms of service, API deprecation policy, and uptime — not the wrapper. The wrapper can be replaced in a day; the vendor relationship cannot.
• Legal/data: the domain is Swedish personal and company registry data, keyed on personnummer. That is sensitive personal data under GDPR and, depending on processing purpose, may touch Article 9-adjacent territory. Adopting this package does not answer the Article 6 lawful basis, the Article 14 transparency obligation (data subjects did not provide this data to us), the DPA with Ratsit, records-of-processing updates, retention limits, or data-subject rights handling. None of that is in scope for the bundle and all of it is on the critical path for us.

Key questions

• What is Ratsit's per-call pricing, monthly minimum, rate limit, SLA, and notice period for API changes?
• Do we have, or can we obtain, a DPA and a documented lawful basis for our specific use case (onboarding pre-fill vs. fraud review vs. CRM enrichment carry different weights)?
• Does the client support injected PSR-18 transport, timeouts, retries, and structured errors — or will we fork it to get them?
• What exact fields are returned, and what is the data freshness/lag versus the official registry?
• Which PHP versions and extensions are required, and does the core pull symfony/*?
• Is the maintainer reachable and is there any stated roadmap or succession plan? Bus factor is 1.
• Does the MIT license cleanly cover the full dependency tree?
• Signal-quality note for governance: the automated scoring inputs for this package conflate "Ratsit" with remote attestation (RATS/RFC 9334). The domain is Swedish people-search, not TPM/SEV attestation. Any evaluation artifact that treats this as a security-verification library should be discarded before it reaches an architecture board.

Integration Approach

Stack fit. Target Laravel 10/11/12 on PHP 8.2+. Do not install the bundle; the symfony/* transitives buy nothing. Confirm Octane and queue-worker safety early — long-lived workers cache container state, so the client must be stateless and free of per-request mutable state (auth tokens aside, which should be resolved per call or refreshed explicitly).

Migration path — four options, in preference order:

Compatibility. Pin the library to an exact version in composer.json, not a caret range — pre-1.0 semver offers no stability guarantee. Register bindings as singletons only where the object is genuinely stateless. Keep the config file free of closures so php artisan config:cache works.

Sequencing.

1. One-week spike: read Ratsit's terms, pricing, rate limits, and GDPR posture; benchmark against two alternates; return a written build-vs-buy and vendor-selection recommendation. No production credentials, no real personnummer.
2. Written ADR covering options A–D, plus a short data-flow diagram showing where personnummer enters, where it is stored, and where it is logged.
3. Define an internal seam — App\Services\Registry\PersonLookup with findByPersonnummer(Personnummer $ssn): ?PersonData — and bind the vendor behind it. Nothing outside the adapter may import Jongotlin\Ratsit\*.
4. Legal and security sign-off before any real personal data flows: DPA executed, lawful basis recorded, retention policy set, notice updated.
5. Build the adapter: personnummer normalisation and Luhn validation at the boundary (including samordningsnummer, day + 60), Redis caching with a defensible TTL, queued lookups, structured error taxonomy.
6. Pilot on internal tooling or a back-office enrichment flow only, behind a feature flag, with a manual fallback.
7. Customer-facing only after a documented outage-mode test and a redaction audit of logs and traces.

Operational Impact

Maintenance. We own the Laravel glue permanently, and we are tracking a pre-1.0 upstream with a single maintainer. Budget for breakage on minor releases, and note that upstream fixes will arrive in Symfony-bundle shape and never apply to our adapter directly — we re-derive them. Mitigate with an internal fork or vendored-patch policy under MIT, a pinned lockfile, and a dependency-diff gate in CI.

Support. MIT with no SLA, no commercial backing, no escalation path. The supportable contract is with Ratsit, not with the package — negotiate terms, rate limits, and change notice with the vendor, and treat the PHP code as unsupported glue we maintain. Name a single internal owner who has read the client's source.

Scaling. The binding constraint is commercial, not technical: billing is per request, so cost scales with call volume rather than CPU. Cache by personnummer for 24h–7d, tag entries for purge-on-request, and do not cache negative results for long — a "not found" may mean the person was registered yesterday. Queue lookups on a low-concurrency worker so a slow third-party call never blocks a web request; back off explicitly on 429s rather than retrying into the rate limit. Model monthly cost at realistic signup volume before committing — a per-lookup price that looks trivial becomes a line item at scale.

Failure modes, ranked by business severity:

1. Silent false negative. An empty or errored response is coerced into "person not found," and a legitimate customer is blocked or mis-scored. Distinguish NotFound from VendorError in the adapter's return type and test it explicitly.
2. Outage on a customer-facing path. Decide per flow: enrichment (pre-fill, CRM) should degrade gracefully and proceed; fraud or identity screening must fail closed to manual review. Undocumented behaviour here is the most likely production incident.
3. PII leakage into logs, traces, and error trackers. Personnummer in an exception message or an APM payload is a reportable incident. Redact at the adapter boundary and audit third-party logging sinks.
4. Legal basis lapse or vendor terms change. If Ratsit revises permitted use or pricing, we must be able to switch vendors without touching call sites — which is what the PersonLookup seam buys us.
5. Dependency conflict blocking a security patch elsewhere in the Laravel application.
6. Maintainer abandonment — no fix path for a future vulnerability in the client.

Ramp-up. Engineering ramp is small: 2–3 days for a competent Laravel developer to wire the client, normalise personnummer, add caching, and write tests. Compliance ramp is the real cost — DPA negotiation, lawful-basis documentation, notice updates, and a retention policy are typically weeks, involve legal and often a DPO, and gate the feature regardless of how fast the code lands. Plan the two tracks in parallel and do not let a green build signal readiness to ship.

Recommendation. Do not adopt jongotlin/ratsit-bundle. Approve a one-week vendor-selection spike that returns a build-vs-buy decision on Ratsit versus two alternates, plus a legal review of the lawful basis for the specific flow. If Ratsit wins on merit, consume the underlying jongotlin/ratsit library behind an internal interface and own the ~100 lines of container glue — that is cheaper than inheriting an unmaintained wrapper, and it is the only version of this decision we can support in production.