What happens
When you generate an API key on Hardcover, you get a value like:
Bearer eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJIYXJk...
If you paste this directly into Athenaeum's Hardcover API key field, requests fail because the code prepends Bearer again:
headers={"Authorization": f"Bearer {api_key}"}So the actual header becomes Bearer Bearer eyJ....
Why this is worth addressing
Other apps in the same space (e.g. Shelfmark) accept the token exactly as Hardcover provides it, Bearer prefix and all. Having to know that Athenaeum wants just the JWT part without the prefix is a small papercut, but it's the kind of thing that makes you waste time wondering why the integration isn't working.
Suggestions
Either:
- Strip a leading
Bearer from the stored key before using it (so both formats work)
- Add a placeholder or hint in the UI field: "Paste the JWT token without the Bearer prefix"
The first option is probably friendlier since it just works regardless of what the user pastes.
Environment
What happens
When you generate an API key on Hardcover, you get a value like:
If you paste this directly into Athenaeum's Hardcover API key field, requests fail because the code prepends
Beareragain:So the actual header becomes
Bearer Bearer eyJ....Why this is worth addressing
Other apps in the same space (e.g. Shelfmark) accept the token exactly as Hardcover provides it,
Bearerprefix and all. Having to know that Athenaeum wants just the JWT part without the prefix is a small papercut, but it's the kind of thing that makes you waste time wondering why the integration isn't working.Suggestions
Either:
Bearerfrom the stored key before using it (so both formats work)The first option is probably friendlier since it just works regardless of what the user pastes.
Environment