- What is sonnenglas/laravel-amazon-mws and what can I do with it?
- It is a Laravel package that wraps Amazon Marketplace Web Service (MWS) in an object-oriented API, giving you a convenient way to query orders and products and to submit reports and feeds. It ships a service provider, a facade, and a publishable config file with per-marketplace credential profiles. In a Laravel app it belongs behind your own interface as an infrastructure adapter, because it contributes no domain logic. MWS is a sunset surface, so treat it as a time-boxed integration rather than a long-term platform bet.
- How do I install laravel-amazon-mws with Composer?
- Run composer require sonnenglas/laravel-amazon-mws and let Laravel package auto-discovery register the service provider and facade. Publish the config file with php artisan vendor:publish and set your MWS credentials there or in your .env file. Because the package metadata targets Laravel ^7.x, verify the actual composer.json constraints before installing into a current Laravel app, and validate provider boot and facade resolution in a throwaway skeleton first. Older wrappers also pin Guzzle 6 or 7, which can conflict with a modern stack.
- How do I configure Amazon MWS credentials and marketplace regions in Laravel?
- After publishing the config you supply your Seller ID, MWS Auth Token, AWS access key and secret tied to your developer registration, plus the region or marketplace mapping (NA, EU, or FE). The package supports per-marketplace credential profiles, so multi-region sellers can keep separate settings. There is no OAuth refresh flow, so plan for secret storage and rotation yourself. All of these values are only obtainable if your account already holds a grandfathered MWS registration.
- Which Laravel and PHP versions does laravel-amazon-mws support?
- Package metadata states Laravel ^7.x, which pairs with PHP 7.4, both of which are end-of-life. The README's claim of compatibility with the latest Laravel should not be trusted over the composer.json. Read the constraints directly and test against your own PHP and Laravel matrix. Adopting it usually means either running an unsupported framework or forking the constraints and owning an upgrade program.
- Is Amazon MWS deprecated, and does this package still work?
- Amazon closed new MWS developer registrations and has been steering sellers to the Selling Partner API for years, but existing grandfathered registrations can still call the endpoints. So the package works only if your organization already holds valid MWS access for the marketplaces you sell in. Endpoint availability, throttles, and report or feed schemas can change without notice, and Amazon support for MWS issues is minimal. Confirm the communicated end-of-life for your account and region before committing.
- Should I use laravel-amazon-mws or the Amazon Selling Partner API?
- If you do not already have an MWS developer registration, this package is a dead end and SP-API is the only path. Even with a registration, SP-API's Login with Amazon model removes the long-lived seller auth token and IAM key rotation burden that MWS imposes. A practical compromise is to wrap this package behind your own MarketplaceGateway interface so an eventual SP-API swap is a single class change. Weigh Amazon's MWS end-of-life date against your ROI horizon.
- How do I mock Amazon MWS responses in tests for this Laravel package?
- The package speaks XML over HTTPS through Guzzle, so you can inject a mock handler or use Laravel's HTTP fake to return canned XML without touching Amazon. No meaningful test coverage is published for this fork, so your CI must not depend on live calls. Persist real request and response payloads from a spike and replay them as fixtures. Confirm how much of the wrapper is easily swappable before you design the suite.
- Does laravel-amazon-mws handle throttling, retries, and queued jobs?
- No, it is a thin convenience wrapper and generally hides the asynchronous error surfaces of feeds and reports, such as feed processing reports, report request status, and throttling responses. MWS is poll-based apart from SQS notification subscriptions, so idempotency and deduplication are yours to build. Move every call into queued jobs with exponential backoff and store raw payloads for replay and audit. Do not assume the package gives you resilience out of the box.
- Who maintains laravel-amazon-mws and is it safe for production?
- It is a small vendor fork of the dormant creacoon/amazon-mws-laravel with roughly 64 stars, zero dependents, and effectively a single maintainer. Assume you own the code and the patches, and vendor it into your repository or pin a fork commit rather than tracking a branch. Check that the fork preserves the upstream Apache-2.0 notices and attribution. For a long-lived production commitment, that maintenance load is a real cost, not a footnote.
- What are the alternatives to sonnenglas/laravel-amazon-mws for Amazon integrations?
- The upstream creacoon/amazon-mws-laravel is the closest alternative, and other MWS wrappers on Packagist behave similarly, so they carry the same deprecation risk. For new work the practical choices are the official Selling Partner API SDKs, community SP-API clients, or a hand-rolled Guzzle client for the handful of MWS calls you actually need. If you only need one or two endpoints, a small custom client behind your own interface is often simpler than any package.