Request Xml Laravel Package

Product Decisions This Supports

• Unblocks XML-first integrations without a custom parsing layer. Many partner/vendor APIs (banking, insurance, logistics, telecom, government/EDI feeds, SOAP-adjacent webhooks) still post XML. This package makes $request->xml() behave like Laravel's native $request->json(), so a team can accept an XML payload in a controller and ship the integration rather than building and maintaining its own parser, middleware, or DTO pipeline.
• Build vs. buy/borrow: the "build" option here is a small but non-trivial in-house utility (parsing, content-type negotiation, namespace/attribute handling, error paths, security hardening). At 43 stars and MIT, this is a borrow-and-vendor decision — low cost, low lock-in, forkable in an afternoon. The real cost is not the package; it is not standardizing, which leads to three slightly different XML parsers across three squads.
• Roadmap shaping: if "accept XML from partner X" is on the roadmap, this converts a multi-day spike into an afternoon of work per endpoint, which changes sequencing — XML intake can be pulled into the current quarter instead of being deferred behind a "request parsing abstraction" epic.
• Feature use cases to evaluate against: legacy vendor webhook receivers, XML config/feed import, RSS/Atom ingestion, payment or status notifications, and internal migration endpoints where a legacy system can only emit XML.
• Risk decision it informs: adopting a small single-maintainer dependency is a deliberate, bounded bet — acceptable when the surface area used is one method call and the fallback is to vendor the file. It should be logged in the dependency register with an owner and a review date, not waved through silently. The 2.7.0 release (Laravel 13.x compatibility) is a positive maintenance signal: the package is still tracking the framework, and the fix arrived as a community PR rather than being left to rot.
• Framework upgrade sequencing: 2.7.0 means XML intake is not a blocker for a Laravel 12 → 13 upgrade. Teams planning a framework bump can carry this dependency forward; conversely, anyone pinned to ^2.6 should plan the bump as part of the upgrade, not after it.

When to Consider This Package

Adopt when:

• The stack is Laravel and the need is genuinely request-level: parse an inbound XML body into an array/collection with the same ergonomics as JSON.
• The scope is a handful of endpoints with modest payloads (< a few MB) and simple or well-understood schemas.
• You want to avoid hand-rolling simplexml_load_string in every controller and want one place to enforce safe parsing defaults (external entity loading disabled, error handling consistent).
• You accept the maintenance profile: small package, few stars, one maintainer — so pin the version, review the source once, and be ready to fork or vendor. Pick ^2.7 on Laravel 13 stacks; ^2.6 remains valid on older framework versions but is the older line.

Look elsewhere when:

• SOAP is the actual requirement. WSDL consumption, WS-Security, and envelope semantics belong to a dedicated client (e.g., phpro/soap-client) — this package will not carry that weight.
• You need real schema validation. XSD validation, typed DTOs, and strict contracts are better served by a validation library or a mapping layer (e.g., spatie/laravel-data with a custom cast) rather than array conversion.
• Payloads are large or streaming. XMLReader-based streaming is the right answer; DOM-based parsing of 100 MB uploads will not end well.
• Supply-chain sensitivity is high. Zero dependents and a low star count mean limited external scrutiny. In a regulated environment, require a source audit and a documented fork strategy — or implement the ~100 lines in-house and own it outright.
• The need is outbound. This is inbound request parsing; serializing responses to XML is a separate concern.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a small, recurring need to accept XML payloads from partners whose systems predate modern JSON APIs. Rather than fund a bespoke parsing component, we can adopt a tiny MIT-licensed Laravel package that adds XML support to the framework's existing request object. It removes roughly the same amount of work per integration as we currently spend on bespoke parsing, carries no infrastructure cost, and is small enough to fork and own if the maintainer stops. Its latest release adds compatibility with the newest Laravel version, so it does not constrain our framework upgrade path. The decision is low-cost and reversible; the main governance action is pinning the version and recording it in our dependency inventory.

For engineering (summary): composer require mtownsend/request-xml (use ^2.7 for Laravel 13.x; 2.7.0 is a compatibility-only release with no API changes, new features, or deprecations), auto-discovered service provider, then $request->xml() yields a parsed structure analogous to $request->json(), with attribute/namespace handling as needed. Two caveats to own on our side: (1) confirm entity/external-resource loading is disabled in the parsing path before it touches untrusted input, and (2) XML has no implicit schema — validation is our responsibility, so add explicit rules per endpoint. Pin the version, vendor the source if the integration is business-critical, and treat upgrading as a deliberate step rather than following ^ automatically.

Decision requested: approve adoption as the standard inbound XML parser for the current integration set, with a dependency-register entry and a six-month maintenance review — or, if policy forbids new low-adoption dependencies, approve the equivalent in-house implementation as a smaller, safer alternative. The 2.7.0 release does not change the recommendation; it removes the "will it survive our next framework upgrade" objection from the discussion.