Weave Code
Spatie Price Api Laravel Package
spatie/spatie-price-api
A small Laravel package that retrieves product prices from the spatie.be API, used on promotional sites for Spatie's own products. Open source but not intended for third-party use.
The Price API used at promotional sites for our own products
Frequently asked questions about Spatie Price Api
- What is spatie/spatie-price-api actually used for?
- It is a small PHP package that retrieves product pricing from the API at spatie.be and is used on the promotional sites for Spatie's own products. Architecturally it is a thin HTTP client plus a Blade and Alpine helper, not a pricing platform. The README states plainly that although it is open source, it is not intended for third-party use. Treat it as a reference implementation rather than a dependency for your own catalogue.
- How do I install spatie/spatie-price-api in a Laravel application?
- Install it with composer require spatie/spatie-price-api. It is Composer-installable, MIT licensed, and pulls in no heavy dependencies, so integration effort is measured in minutes rather than days. The entire server-side surface is a single static call, SpatiePriceApi::getPriceForPurchasable(), which returns pricing information for a purchasable model. Verify the package's PHP and Laravel constraints against your app before committing.
- Which Laravel versions does spatie-price-api support?
- The release history is essentially Laravel version bumps for Laravel 10, 11, 12 and 13, plus one Alpine feature release in 1.7.0. That cadence reflects Spatie's own upgrade schedule, not yours, so check the composer.json constraints on the tag you intend to pin. Because the package is maintained against Spatie's release calendar, a new Laravel major may land later than your own upgrade window. Pin a version and plan to review it at each framework major.
- Can I use spatie-price-api to fetch prices for my own products?
- No. The package is hard-coupled to spatie.be, the backing endpoint is undocumented and unversioned, and the maintainers explicitly say it is not for third parties. Adopting it would pin your promotional pricing to someone else's internal contract with no migration path if the response shape changes. Packagist shows zero dependents, which matches that intent. Build an equivalent client against a pricing source you control instead.
- Does spatie-price-api render prices server-side for SEO and no-JS users?
- As of 1.7.0 the price-resolution boundary moves to the visitor's browser: scripts() registers Alpine components that fetch the price client-side. That means the price is absent from the initial HTML, which is bad for crawlers, listing pages, and non-JavaScript users. If a surface needs the price indexed or visible without JS, add a server-rendered fallback using the getPriceForPurchasable() call. Plan that fallback before you ship, not after.
- What does SpatiePriceApi::scripts() do and where should I include it?
- It registers the spatiePrice(id) and spatieBundlePrice(id) Alpine components along with a discount countdown. It injects JavaScript, so verify how it interacts with your Vite entry points and your Content Security Policy before assuming inline injection is acceptable. If you run Vue, React, or Inertia, you would re-implement the components anyway. The components are roughly 50 lines each, so rewriting them is often cheaper than the governance overhead of an unsupported dependency.
- Is the price returned by spatie-price-api authoritative at checkout?
- No. The browser-side fetch and the countdown are advisory and display-only, because both a client clock and a client fetch are untrusted. Expiry, eligibility, and discount application must be re-validated server-side at the cart and checkout steps. If anyone treats the displayed discount as authoritative, you have a pricing-integrity incident waiting to happen. This is the main reason to keep the package out of any authoritative pricing path.
- What happens if spatie.be is down or rate limits my requests?
- There is no provider abstraction, no local price store, and no fallback dataset, so a synchronous external call sits on the render path. Spatie-side downtime or rate limiting becomes your promotional page showing no price at all. If you adapt this pattern, wrap the HTTP call with a cache and a fallback price so a failed fetch degrades gracefully. That availability risk is rated high in any production review of this package.
- How do I test spatie-price-api or a re-implementation of it?
- The package ships with a test suite you can run via composer test. For your own client, fake the HTTP layer with Laravel's Http::fake() so tests do not hit a live endpoint, and assert on the pricing DTO the response maps into. Also test the failure path: a timeout, a 500, and an unexpected payload shape should all fall back to a known price rather than throwing on the render path. Those are the cases that break promotional pages in production.
- What are good alternatives to spatie-price-api for a Laravel pricing page?
- The realistic path is a reference-implementation read of roughly half a day followed by building your own equivalent, which is scoped at about two engineer-days for a spike. Keep the same clean shape, a thin client feeding a pricing DTO, a Blade helper, and an Alpine component, but point it at a source you control with a provider abstraction and a cache. Note what the package deliberately does not do: checkout totals, tax, entitlements, coupons, contract pricing, multi-currency conversion, and seat-based or metered pricing. That is usually where real pricing complexity lives.
Weaver
How can I help you explore Laravel packages today?