Customer ID best practices
Immutability, prefixes, zero-padding, uniqueness constraints and guessability — the rules that keep customer IDs working for decades.
Customer IDs live for decades — longer than the systems that create them, sometimes longer than the companies. These practices keep them working that long.
1. Never change an ID
The single most important rule. An ID's whole value is permanence: invoices, support tickets, integrations and exports all reference it. If IDs can change, every downstream system needs a migration path, and most will not have one. Pick the scheme carefully, then treat issued IDs as immutable.
2. Never encode volatile facts
Region codes, plan tiers, acquisition channels — all change. An ID like CUS-US-PRO-01042 becomes a lie the day the customer moves or downgrades. Encode only facts that are true forever (a type prefix like CUS) or nothing at all. The year is the classic trap: CUS-2024-01042 is fine for a cohort label, questionable as a permanent ID.
3. Use clear, short prefixes
A 2–4 letter uppercase prefix (CUS, USR, MBR) prevents the most common ID bug: passing one kind of ID where another was expected. Keep a registry of prefixes per record type, and avoid near-duplicates — CUS and CUST in the same system is asking for trouble.
4. Zero-pad sequential numbers
CUS-01001, not CUS-1001. Fixed-width numbers sort correctly as plain text, align in tables, and look intentional. Choose a width with headroom: 5 digits covers 99,999 customers, 6 covers 999,999. Running out of width is a painful migration — overshoot early.
5. Enforce uniqueness in the database
A unique constraint (or unique index) on the ID column is the real guarantee — not the generator, not the application code. Application-level "check then insert" has a race condition; the database constraint does not. This applies doubly to random IDs: collisions are unlikely, but "unlikely" is not a guarantee.
6. Match guessability to exposure
| Exposure | Recommended | Why |
|---|---|---|
| Internal only (support desk, admin) | Sequential, prefixed | Readable, sortable, phone-friendly |
| Customer-visible (invoices, accounts) | Sequential or random | Sequential is fine; random adds privacy |
| In URLs or share links | Random, 80+ bits | Sequential IDs in URLs are enumerable |
| Access-adjacent (resets, invites) | Random tokens, not IDs | IDs identify; tokens authorize — different jobs |
7. Keep IDs separate from secrets
A customer ID identifies; it does not authenticate. Never use an ID as a password-reset token, an API key, or proof of ownership. If an ID appears in a URL, anyone with the URL can see it — design accordingly.
8. Plan the width and alphabet once
Decide the character set (avoid ambiguous characters like 0/O and 1/I if humans will type IDs), the total length, and the prefix registry — then write it down. Future systems, integrations and data migrations will all conform to this document. The generator's three tabs mirror the three schemes worth standardizing on.