Laravel Model Hashids Laravel Package

Product Decisions This Supports

• Public-facing identifier strategy — this package swaps auto-incrementing primary keys for obfuscated, reversible hashids at the model boundary. That is a product decision (what a customer sees in a URL, API payload, or share link), not just a technical one. This release confirms the package is a viable long-term dependency for that decision.
• Anti-enumeration and scraping posture — sequential IDs leak volume ("we're customer #412") and invite crawling. Choosing hashids is a cheap, reversible mitigation; knowing it works on Laravel 13 lets you commit to it before public launch rather than retrofitting after an incident.
• Upgrade runway for the platform — Laravel 13 support means the identifier layer is not the thing blocking a framework upgrade. That directly de-risks roadmap planning for the next 12–18 months: no "we can't move to 13 because our ID package is abandoned" fork in the road.
• Build vs buy — the alternative is a homegrown trait + Hashids wrapper (roughly a day of work, plus tests, plus ongoing maintenance). At v4.1.0 with CI coverage across Laravel 11/12/13 and both dependency resolution modes, buying (adopting) is the lower-total-cost option for any team without unusual encoding requirements.
• Use cases this unlocks concretely — shareable links that don't disclose record counts, multi-tenant references where IDs cross tenant boundaries, customer-facing exports, and any API surface where GET /orders/1043 is a business-intelligence gift to a competitor.
• Not a decision this supports — this is not a security control. Hashids are reversible with the salt; treat this as obscurity and UX, not authorization. Any roadmap item premised on "IDs are now unguessable, so we can skip the policy check" should be killed.

When to Consider This Package

Adopt when:

• You expose record identifiers to end users in URLs, APIs, emails, or exports, and you want them non-sequential without migrating to UUIDs/ULIDs.
• You want to keep integer primary keys (fast joins, small indexes) while decoupling the external identifier — this is the package's core value proposition versus a UUID primary key.
• You are on Laravel 11, 12, or 13 and PHP 8.3/8.4. The v4.1.0 matrix explicitly covers prefer-lowest as well as prefer-stable, which is a meaningful signal of dependency hygiene — it means the package is tested against the oldest allowed versions, not just the newest.
• You need a drop-in upgrade story. v4.0.x → v4.1.0 requires no code changes, so piloting it on one service is genuinely low-risk.

Look elsewhere when:

• You are pre-Laravel-11 or on PHP below 8.3. The compatibility table starts at Laravel 11 / PHP 8.3. Teams on Laravel 10 or PHP 8.1/8.2 are on an unsupported path and should not adopt.
• You need irreversible, collision-resistant, or sortable identifiers. UUIDv7/ULIDs or a proper id + public_id scheme serve that better; hashids are reversible and not sortable.
• You need authorization guarantees. Do not let this package substitute for policies, signed URLs, or scoping.
• You have regulatory or audit constraints on identifier opacity — a salted reversible scheme with a leaked salt is fully decodable. If the threat model includes a determined attacker with config access, this is the wrong tool.
• You need high-throughput bulk encoding — verify against your own benchmarks; small single-record encode/decode is the common case, batch paths less so.

Given the v4.1.0 signal specifically: the formatting-only Pint changes and the widened testbench dev constraint carry no product risk, so prior adopters have no migration work and no reason to hold back.

How to Pitch It (Stakeholders)

For executives (one line): A small, actively maintained library that stops our public URLs and API responses from leaking how many customers, orders, or records we have — and the new release confirms it won't block our Laravel 13 upgrade.

For engineering (the substance):

• v4.1.0 is a compatibility release: adds Laravel 13 (illuminate/contracts ^13.0), keeps Laravel 11 and 12 fully supported, drops nothing. PHP 8.3 and 8.4 only.
• Upgrade is composer update — no code changes, no migration, no config changes. The rest of the diff is Pint formatting.
• CI now runs Laravel 13 on PHP 8.3 and 8.4 across both prefer-lowest and prefer-stable resolutions, which is stronger coverage than most packages of this size provide.
• The important framing: this is obscurity, not security. It removes sequential-ID enumeration; it does not authorize access. Policies and scoping stay exactly as they are.
• Recommended next step: adopt on one externally-facing service, keep integer primary keys internally, and treat the hashid as a presentation-layer concern. Re-evaluate if we ever need sortable or irreversible public identifiers — that's a UUIDv7 conversation, not a bug in this package.