Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Beautiful API Keys

docs.agentstation.ai

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Making Beautiful API Keys

#61

Post by Retr0id »

stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

All things in moderation. I think they're correct to classify their API keys as part of their user interface. It's less like deciding the colour of the bike shed, and more like deciding whether the metal sides of the new iPhone should have a brushed or polished finish. Sure, it doesn't affect anything practical, but it may well influence how the user feels about the product. Maybe you deny having feelings about APIs but I think you'd be lying ;)

All that said, I'm not sure the juice was worth the squeeze here - I don't think their new API keys look any more beautiful than a standard UUID. I like that they cared all the same, though.

Re: Making Beautiful API Keys

#62

Post by alt227 »

felideon wrote: post #57
stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

Their customers are developers, their product is a dev tool. No different than any other company obsessing over great UX. Stripe won because of the developer experience.

Tangent, but same with Quickbooks Online. Seems most accountants and bookkeepers I have spoken to hate it, however it has a really useable api and simple callback system which makes it super attractive to developers.

No surprise then that it is the worlds most used accounting software, even though most of its users hate it.

Re: Making Beautiful API Keys

#63

Post by fbuitron »

stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

Sometimes someone caring about details is what makes everything better.

Nobody is going to choose their product just because their API Keys.

But they are generating a halo effect. Is like going to a restaurant with outstanding bathrooms. If they put a lot of care in that, you immediately assume they do the same in all the other aspects of their product/service.

Re: Making Beautiful API Keys

#64

Post by dewey »

stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

Sometimes spending engineering time for content marketing is worth more than implementing some feature that's not needed for the early adopters.

Re: Making Beautiful API Keys

#65

Post by mrweasel »

notpushkin wrote: post #4
mtmail wrote: post #3

"encodes UUIDs to a readable Key format via the Base32-Crockford codec and also decodes them back to UUIDs." Example: "d1756360-5da0-40df-9926-a76abff5601d" => "38QARV0-1ET0G6Z-2CJD9VA-2ZZAR0X" I think now you risk having 0 vs O or I vs 1 readability issues. [edit: good news, I was wrong]

Base32-Crockford doesn’t have 0 and 1 for this exact reason! (Seems uuidkey authors have decided to remove O and I instead, but the effect is the same) EDIT: I’ve looked it up and I was wrong! Crockford alphabet does use all digits (0–9), but doesn’t have O, I or L. When decoding, O is mapped back to 0 and both I and L are mapped to 1. Sorry for the confusion!

Given that API keys are likely to simply be copy-pasted, I don't honestly think this matters all that much.

If you're have the risk to users confusing 0 and O, then you can't use either. Your users aren't going to know that you're running Base32-Crockford and that they'll only encounter 0 and 1, never O, I or L.

We did a "password" generator, for people who made a purchase, but didn't want an account. To view an order they'd then need to enter a code, found in their confirmation email. Those codes where really short, 8 or 10 characters, no 0,1,I,O,L,U,V and all upper case. If the user entered the code in lower case, we'd automatically upper case it. You'd never use these as a real password, but for a temporary order tracking page they pretty much removed all of the input mistakes people could make.

Re: Making Beautiful API Keys

#66

Post by Merad »

robertclaus wrote: post #10

This type of key editing always makes me nervous. I know how uuids behave. I'm not a security expert, but I'm 99% sure the formatting steps here don't increase the chance of key collisions or security implications significantly. Is that 1% risk worth it?

Base 32 is just an encoding, so it doesn't modify the underlying data of the uuid, it presents the data in a different display format. It's the same as how the number 10 can be represented as decimal 10, binary 0b1010, octal 0o12, hex 0xA, etc.

Re: Making Beautiful API Keys

#67

Post by xdennis »

notpushkin wrote: post #8
theamk wrote: post #2

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.

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

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

E.g.: user_2x4y6z8a0b1c2d3e4f5g6h7j8k

Re: Making Beautiful API Keys

#68

Post by ripped_britches »

stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

I’d say, besides writing this blog post, it probably took someone about a couple of hours to look up the available options and come to a decision. If that’s true, well worth the extra thought for their customers. It takes lots of painstaking focus like that to make a great product. But yes, if they spent weeks on this it would be too much.

Re: Making Beautiful API Keys

#69

Post by inexcf »

alt227 wrote: post #56
xirdstl wrote: post #45

Earlier quoted context omitted.

They realized that and were pleased with themselves. > The dashes do remove easy double-click copying, but we think this a fine trade off for readability. We don't want users copying and pasting them everywhere, in fact we want them to be handled with care. Ideally, users copy each key exactly once - when they generate the key from our dashboard - so we added a copy button to our UI to solve that case Don't even thin…

This statement makes me never want to use their product.

I agree. They seem to focus on completely useless stuff that actively makes it worse to use.
Post reply on HN