[theamk]

One of the best things you can do to your API key is to give it a fixed prefix. Makes it very easy to tell that you have the right string, to detect accidental secret leakage, etc...

IMHO this makes key much more beautiful than any internal structure.

[moebrowne]

Agreed. I like what GitHub did with their API tokens, not only adding prefixes but also a checksum.

https://github.blog/engineering/platform-security/behind-git...

[adriancooney]

Agreed. I first seen it at Stripe (along with prefixing every ID). Whoever at Stripe (or where ever it was invented) needs a good pat on that back. It's adoption has been a huge for DX generally.

[jjice]

I'm a big fan of prefixed keys as well. If I could go back in time, I would've made my current company's API keys prefixed. Sometimes you'll chat with a customer and just notice the same isn't right and realize the key is all wrong. It's a lot easier if it starts with `company_XXXXX`. Also denoting environment (live vs test in Stripe) with a prefix is actually critical in my eyes.

I also like prefixed resource IDs. Stripe is the first one that comes to mind, but I've run into it multiple times where a customer is describing an issue and it turns out the ID they're trying to lookup is for a different resource (often similar). You don't get those accumulated hours of support time back...

[dspillett]

I would agree with that.

Also, I don't really want API keys and such to be generally pretty. If things that have no business being end-user facing are ugly then they are less likely to be allowed to accidentally become end-user facing.

If being pretty or otherwise user-friendly is a priority, then I'd go with trying to make them readable/pronounceable rather than shorter, even if that actually makes them longer. There are numerous projects out there¹²³ for doing just that. You could even use the 256-word example³ with multiple small dictionaries, and give people a choice from various possibilities that map to the same number.

----

[1] https://github.com/Debdut/uuid-readable

[2] https://github.com/Martichou/uuid-readable-rs

[3] https://github.com/anton-bot/guid-in-words

[yread]

I like adding a suffix as well: (optional) human readable expiration date

[notpushkin]

I’ve made a library for that! https://codeberg.org/prettyid

[dewey]

Why should anyone vendor a dependency in a critical functionality for three lines of code (https://codeberg.org/prettyid/js/src/branch/master/lib/index...)?

[HideousKojima]

That's the JavaScript/Node ecosystem in a nutshell. See the LeftPad fiasco and the mere existence of the IsOdd and IsEven packages for more poor judgement.

[notpushkin]

To be honest that’s because I didn’t flesh out JS counterpart yet. My plan was to have something similar to the Python version: https://codeberg.org/prettyid/python

Of course, if you like the idea but don’t want to add another dependency, you can copy-paste the three-liner as it is! (And I’m sure it’s not even copyrightable right now :-)

[fusspawn]

multiple dependencies,

Also requires two other packages to run its 3 lines of code.

"dependencies": { "@scure/base": "^1.1.7", "uuidv7": "^1.0.1" }

[kqr]

...but you'll have those dependencies anyway!

[verdverm]

only if I can leftpad it first?

[xdennis]

There's a similar proposal called TypeID: https://github.com/jetify-com/typeid

E.g.: user_2x4y6z8a0b1c2d3e4f5g6h7j8k

[notpushkin]

This is actually pretty good! And it seems to be compatible with my implementation (it’s also UUIDv7 and base32 alphabet is the same, but without mapping from OIL to 01).

[progforlyfe]

actual functional features in API keys! How dare you! aesthetics over all!!