Eloquent Hashids Laravel Package

Product Decisions This Supports

• Public identifier strategy: Decides whether to expose raw auto-increment IDs in URLs/APIs or hash them. This package makes the "hashids now, UUID later" option cheap to trial.
• API surface & URL design: Route model binding by hashid lets you ship /orders/x7Kp2 style routes without changing controllers, so it informs naming, versioning, and backward-compatibility commitments.
• Security/compliance posture: Reduces ID enumeration and IDOR-style scraping of sequential IDs — relevant to any roadmap decision gated on "don't leak record counts or growth rate."
• Build vs. buy: A 291-star package vs. hand-rolling a Hashids trait, vs. migrating to UUID/ULID primary keys. It's the lowest-effort option and a useful benchmark for the "just do it ourselves" estimate.
• Retrofit vs. greenfield roadmap calls: Because it requires no schema migration, it supports decisions to harden an existing app incrementally rather than block on a data-model rewrite.
• Feature use cases: share links, public profile/order/invoice URLs, invite or referral codes derived from entity IDs, and lightly gated public API resources.

When to Consider This Package

Consider it when:

• You're on Laravel with Eloquent models using integer primary keys and want opaque public IDs without migrations or new columns.
• The goal is obfuscation and enumeration resistance, not cryptographic secrecy — you accept that hashids are reversible by anyone holding the salt.
• You want fast route model binding and zero extra queries, and a trait-based integration your team can adopt in an afternoon.
• You need per-model salts/lengths and want them config-driven rather than hard-coded.

Look elsewhere when:

• You need genuinely unguessable, non-reversible identifiers (use UUIDv7/ULID or random tokens with a lookup column).
• IDs are themselves sensitive or the salt could leak through client code, logs, or shared configs.
• You require stable public IDs across environments/salt rotation, or you're exposing IDs to third parties who may cache them long-term.
• You're not on Laravel/Eloquent, need distributed ID generation, or expect to move to UUID PKs anyway — adopting hashids first adds a migration step later.
• You need sortable public IDs or human-readable slugs — a slug package is the better fit.

How to Pitch It (Stakeholders)

To executives: This is a low-cost security hygiene win. Today our URLs expose sequential database IDs, which reveals how many customers/orders exist and makes scraping trivial. This package hides those IDs in public-facing links in roughly a day of engineering, with no database changes and no downtime. It's a reversible obfuscation layer, not encryption — we should frame it as reducing casual exposure, not as a compliance control.

To engineering: It's a single trait (HasHashId) plus config for salt/length/alphabet. Hashids are computed on the fly from the integer PK, so there's no schema change, no extra column, no extra query, and route model binding resolves hashids back to models. Integration is contained to models and routes; rollback is deleting the trait. The trade-off to accept explicitly: hashids are reversible given the salt, so keep the salt out of client bundles and rotate it deliberately — rotating invalidates previously shared links. If we later need non-reversible or distributed IDs, we migrate to UUID/ULID, and this package is a clean intermediate step rather than a dead end.