Is it safe to use Sqids instead of UUIDs for public API IDs?

Exposing raw internal IDs in your API (like /users/1 or /orders/42) is risky because it makes enumeration trivial and leaks information about your database. One option is UUIDs, but they’re long, ugly in URLs, and slower to index. A practical alternative is Sqids (or Hashids), which encodes internal IDs into short, URL-friendly strings. The key point: these encoded IDs are never stored in the database. Your internal IDs (BIGINTs) stay as primary keys for fast queries, while Sqids are generated on-the-fly when sending data to clients and decoded back when receiving read/update/delete requests. This gives you obfuscation, compact URLs, and stateless encoding/decoding, without impacting database performance.

Sqids works best in single-node or coordinated systems, while UUIDs remain necessary for distributed systems requiring global uniqueness. The workflow is simple: encode internal IDs before sending responses, decode incoming IDs to look up the database, and keep your salt secret to prevent reverse-engineering. This approach gives you short, safe, reversible public IDs, improves API usability, and avoids storing extra data, making it ideal for public-facing endpoints.