Spatie Price Api Laravel Package

Product Decisions This Supports

• Build vs. buy — and here the answer is "build, using this as a reference." The package is a ~1-class HTTP client plus two Alpine components (roughly 50 lines each) for fetching prices and running a discount countdown. It demonstrates a clean promotional-pricing pattern but is explicitly not intended for third-party use, its endpoint is undocumented and unversioned, and it has zero dependents. The decision this informs is whether to spend ~2 engineering days building an internal equivalent behind our own pricing source, versus carrying an unsupported dependency. The former is the recommendation.
• Promotional page velocity. The underlying product problem the package solves is real: marketing wants to ship a campaign landing page with live pricing and a discount countdown without an engineering deploy. The Alpine components fetch price client-side, so a promo page can ship without a backend change. If campaign velocity is a recurring need, fund a small reusable internal version once rather than treating each promo page as a bespoke project.
• Where price can be client-side vs. must be server-rendered. The package makes the trade-off visible: client-side fetch keeps promo pages deploy-light and inherits any regional/localized pricing the API returns, but it leaves the price out of the initial HTML — which is wrong for SEO-relevant pages, listing pages, and no-JS users. This is a per-surface product decision (campaign landing pages: fine; catalogue and product pages: no), not a technical detail.
• Trust boundary for discount urgency. The countdown and displayed discount are advisory. If anyone downstream — checkout, support, finance — treats the displayed number as authoritative, that is a pricing-integrity incident. This forces an explicit decision on who owns server-side re-validation of expiry and eligibility at cart and checkout.
• Experiment framing. Countdown-vs-none and bundle-framing-vs-unit-framing are cheap, measurable A/B tests with clear success criteria (conversion delta, no regression in checkout integrity). A two-day spike buys a real answer either way.
• Roadmap deprioritization: real pricing complexity. The package does not touch checkout totals, tax, entitlements, coupons, contract pricing, multi-currency conversion, or seat-based/metered pricing. Evaluating it is a useful reminder that our actual pricing work lives there, not in display.

When to Consider This Package

Consider it when:

• You are on Laravel 10–13 with Blade + Alpine (i.e., Livewire 3), so the front-end half is at least conceptually reusable.
• You need a reference implementation to read — half a day — before writing your own price client and Alpine components.
• You want a sanity check on the pattern: thin client → typed price DTO → Blade helper → Alpine component → display-only countdown.

Look elsewhere — or, more accurately, do not adopt it — when:

• You need an authoritative price. Price is a business-critical value, and this package couples it to a host we do not control (spatie.be) with no provider abstraction, no local price store, and no fallback dataset.
• You need availability guarantees. There is a synchronous external call on the render path with no fallback; upstream downtime or rate limiting becomes a promo page showing no price.
• You need an SLA, deprecation policy, or a channel to escalate an issue. Support is best-effort from a vendor using the package for its own sites.
• You need initial-HTML prices for SEO, crawlers, or no-JS users.
• You are on Vue/React/Inertia — the Alpine half is not reusable and only the server-side client pattern transfers.
• You have CSP constraints that forbid the inline JS injected by scripts(), or a Vite asset pipeline that expects bundled entries.
• You need any of: tax, coupons, contract pricing, multi-currency conversion, entitlements, cart totals, metered billing. That is where real pricing complexity lives and this package has none of it.

The honest test: is there any scenario where our promotional pricing legitimately reads from spatie.be? Expected answer is no. If no, this is a pattern study, not an integration.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source package from Spatie that fetches live product prices and drives discount countdowns on promotional pages. The pattern is worth copying; the package is not something we should install. It is explicitly not built for outside use, it pulls a number we sell against from a vendor endpoint we don't control and that could change without notice, and it has no users other than Spatie themselves. Recommendation: spend two engineering days building a small internal equivalent backed by our own pricing source, run it on one promotional page as an A/B test against no countdown, and decide on the conversion data. Cost is two days; the alternative is a silent pricing outage on a page we sell from.

To engineering: This is a pattern reference, not a dependency. Read it for half a day: one static call (SpatiePriceApi::getPriceForPurchasable()), a scripts() helper registering spatiePrice(id) / spatieBundlePrice(id) Alpine components, and a countdown. Then build ours behind an interface, backed by our own pricing source, with caching and a typed DTO and a server-rendered price in initial HTML. Sequence matters: interface and DTO first, server-rendered price second, Alpine enhancement and countdown third, measurement last. Doing the client component first inverts the dependency and bakes in the upstream package's core mistake. Roughly 50–100 lines to own. Do not composer require it into a production service.

To marketing: The capability you asked for — ship a promo page with live pricing and urgency without waiting on an engineering deploy — is achievable, but not by installing this package. We can build it internally in about two days and it will be more reliable, because the price will come from our own system and will render in the page HTML, which also helps search and non-JavaScript visitors. The countdown will be display-only by design: it drives urgency, it does not set the actual discount, which is still validated at checkout. We will test it on one page first so we know whether it lifts conversion before rolling it out.

To finance/legal: No third-party data processor is introduced. The vendor endpoint is not used, no visitor pricing data leaves our infrastructure, and MIT licensing is moot since we are re-implementing rather than depending.