Laravel Hashid Laravel Package

Product Decisions This Supports

• Public identifier strategy (primary decision). Whether to expose database primary keys in URLs and APIs at all. This package lets a team keep integer PKs internally while shipping short, URL-safe, non-sequential tokens externally — a decision that touches API contracts, SEO/links, partner integrations, and support tooling.
• Enumeration and scraping exposure. Sequential IDs (/orders/1043 → /orders/1044) let anyone walk your dataset, estimate volume, and harvest records. Adopting hashids is a cheap, reversible mitigation that reduces bulk enumeration without a schema change. It informs the broader security roadmap: obfuscation is a layer, not a substitute for authorization and rate limiting.
• Business-metric leakage. Sequential IDs advertise growth rate, customer counts, and order velocity to competitors, partners, and anyone with a browser. Hiding that is a legitimate (if modest) competitive-intelligence decision.
• Build vs. buy vs. already-have. Three realistic options: (a) write/maintain your own encode/decode + validation + route binding, (b) adopt this package, (c) move to non-sequential primary keys (UUIDv7/ULID/Snowflake) or encrypted IDs. This is a classic "small dependency beats bespoke crypto-adjacent code" call — the package bundles the facade, validation rule, route-model binding, and config layering you would otherwise hand-roll.
• Feature and use-case fit. Customer-facing share links, invite/referral codes, invoice and order numbers, public document IDs, tenant slugs, webhook payload references, and any "copy this link" surface where a readable counter is undesirable. Also useful for inbound decoding: parsing a hashid from a request back to an integer for lookup, with a validation rule to reject malformed tokens before they hit the database.
• Data model and storage posture. Choosing deterministic, stateless encoding over a persisted public_id column — saves a migration, an index, and a backfill, at the cost of being tied to a salt you must never rotate carelessly (rotating it invalidates every previously shared link).
• Rollout/backfill scope. Because encoding is stateless, this supports a phased launch: emit hashids on new surfaces while old integer links remain readable, then deprecate. That is a roadmap sequencing decision, not just a technical one.
• Analytics and sortability trade-off. Non-sequential IDs break "sort by ID" and make debugging/log correlation harder. Deciding this is acceptable is a product decision about internal tooling ergonomics versus external privacy.

When to Consider This Package

Adopt when:

• You are on Laravel with auto-increment integer keys and those keys are visible in URLs, APIs, exported links, or emails.
• You need identifiers that are reversible (you must decode back to the PK) and short (UUIDs are long and hurt link aesthetics and copy/paste UX).
• You want no schema change and no extra storage — deterministic encoding from the integer.
• You want batteries-included Laravel ergonomics: facade, per-model connections/salts, a validation rule, route-model binding, and Blade helpers.
• You need scoped salts per entity so a user hashid cannot be replayed as an order hashid.
• Your team is small and the alternative is a bespoke utility class nobody wants to own.
• The threat model is "casual enumeration," not "determined attacker."

Look elsewhere when:

• You need actual secrecy. Hashids is encoding, not encryption. Anyone with the salt decodes everything. For access-controlled resources, the answer is policies/gates, signed URLs, and scoped tokens — this package is not that.
• You need globally unique, distributed, or sortable IDs. Use UUIDv7/ULIDs or a snowflake generator. If IDs must be generated client-side, offline, or across services, hashids is the wrong tool.
• You need IDs that are genuinely opaque. Encrypted IDs (Laravel's Crypt) or random tokens stored server-side are the honest options.
• Sortability, sharding, or time-ordering matters for internal operations or database locality.
• Maintenance risk is unacceptable. ~416 stars and a single-maintainer profile on a package that sits in the request path means you should assess the bus factor. Mitigation: it is a thin wrapper over the well-known hashids/hashids PHP library, so the exit cost is low — but note that the upstream Hashids algorithm has been effectively superseded by Sqids, and the ecosystem is drifting that way. Budget a swap path.
• You already have UUIDs/public IDs, or your IDs are never user-visible. Adoption here is pure cost.
• You are not on Laravel — use the underlying library directly.
• Salt leakage would be catastrophic and unavoidable (e.g., client-side bundles, open-source configuration). A reversible scheme with a shippable secret is a poor fit.

How to Pitch It (Stakeholders)

For executives: Our URLs currently expose raw database counters — anyone can change a digit and walk through our customers, orders, and invoices, and our growth rate is publicly readable. This package closes that off with short, shareable, non-guessable-looking links, at effectively zero infrastructure cost (MIT-licensed, no new service, no schema change). It is a low-risk, fast-to-ship hardening step for any customer-facing link, and it supports a phased rollout so nothing breaks. The one thing to be clear about: it raises the cost of casual enumeration; it does not replace access control, which we still need. Success looks like fewer sequential-ID probes in the API logs and no change in latency or link UX.

For engineering: A Laravel-native wrapper around Hashids — facade, per-model connection with its own salt, validation rule, route-model binding, and Blade helper. Stateless and deterministic: decode(encode($id)) === $id, so no migration, no new column, no backfill. Integration is typically an afternoon: configure connections, add the trait or route binding, swap ID generation at the serialization boundary. Two caveats to design around: treat the salt as a secret (rotating it invalidates every issued link — version it if you must), and remember it is obfuscation only, so authorization stays in policies. Maintenance surface is small and the underlying algorithm is a well-understood library, so if we ever want out, swapping to Sqids or an encrypted-ID scheme is contained to the codec layer — provided we keep encoding behind a single interface rather than sprinkling facade calls through controllers.