3 ms·
Reducing friction is a good idea but I would argue that asking folks to generate and send you a secret is likely the same amount as them getting an API key that
by bhargav 6y ago
Reducing friction is a good idea but I would argue that asking folks to generate and send you a secret is likely the same amount as them getting an API key that you generate for them. You’ll also run into uncertainties in secret key formats that are used by disparate clients.
If you really want to: One alternative would be to generate a random JWT while the developers are on the website and ask them to secure a given JWT by adding their email, doing on boarding that way.
Addendum: In terms of reducing friction, if this is going to be a paid API, I would suggest adding a free tier that allows N requests before you either rate limit or cut off, and send an email to ask for a conversion
- dyml 6y agoHmm.. you're right that it might introduce uncertainty about key formats, allowed chars/length etc. I'd like to avoid JWTs and use the simplicity of "Basic" (username/password)... but borrowing your idea I could generate it clientside on the website? Enter email and immediately display a API key (base64 of email+random secret/guid) that is stored ("activated") when the first API call hits the server. If you try to call the API with same email but different secret, it's 401. It's indeed going to have a free tier with throttling. A paid tier with other rate limits and some premium features might come down the road.