Fix critical auth: send access-token header instead of Authorization: Bearer#9
Merged
pimfeltkamp merged 2 commits intomainfrom Apr 28, 2026
Merged
Conversation
Critical: every authenticated request was being rejected by the AWS API Gateway in front of api.cryptohopper.com/v1/*. The gateway routes the `Authorization` header into a SigV4 parser and returns `405 Missing Authentication Token` — there's no Bearer-token authz on these routes. Cryptohopper's Public API v1 uses `access-token: <token>` instead. Confirmed by: - https://www.cryptohopper.com/api-documentation/how-the-api-works explicitly says: 'access-token - Your access token received with the Oauth2 authentication' - cryptohopper-ios-sdk/Cryptohopper-iOS-SDK/SharedModels/ConfigModels/ HopperAPIRequest.swift:248 sends `access-token` for v1 calls (and `Authorization: Bearer` only for the V2 admin API) - cryptohopper-android-sdk/sdk/src/.../HopperAPIRequest.kt:331 same - cryptohopper/code-samples/curl/README.md uses `-H "access-token: [ACCESS TOKEN]"` Bump to 0.4.0-alpha.2. No public-API change — `client.user.get()`, `client.hoppers.list()`, etc. keep their signatures. Only the wire-level header sent on each request changes. Test suite updated to assert the new header; 67/67 pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced Apr 27, 2026
The Exchange and Marketplace sections claimed those endpoints accepted anonymous calls. The auth-header fix in this PR establishes that EVERY endpoint on api.cryptohopper.com/v1/* requires a real token (the AWS API Gateway has no anonymous routes), so the README labels were misleading. Replaces them with comments that match reality.
Contributor
Author
|
Pushed a small follow-up commit ( |
pimfeltkamp
added a commit
to cryptohopper/cryptohopper-cli
that referenced
this pull request
Apr 28, 2026
* Bump @cryptohopper/sdk to ^0.4.0-alpha.2 (auth header fix) The CLI's underlying SDK sent Authorization: Bearer <token> which the AWS API Gateway rejects on api.cryptohopper.com/v1/* (returns 405 Missing Authentication Token). The fix in @cryptohopper/sdk@0.4.0-alpha.2 switches to access-token: <token>. This PR picks up that fix and bumps the CLI to 0.6.0-alpha.2. No CLI surface change. Blocked on: cryptohopper/cryptohopper-node-sdk#9 (must merge and publish to npm before this CLI release can install the new SDK). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Drop 'public ticker (no auth)' README claim (matches the dep bump) The Quickstart claimed 'cryptohopper ticker' worked without authentication. The auth-header fix in the underlying SDK (@cryptohopper/sdk@0.4.0-alpha.2, picked up by this PR's dep bump) establishes that EVERY endpoint requires a real token. The CLI inherits that — every subcommand including 'ticker' needs you to have run 'cryptohopper login' first. * Regenerate package-lock.json for @cryptohopper/sdk@0.4.0-alpha.2 The original PR bumped package.json's caret to ^0.4.0-alpha.2 but left the lockfile pinning the older 0.4.0-alpha.1, causing `npm ci` in CI to fail with EUSAGE (manifest/lockfile mismatch). Now that 0.4.0-alpha.2 is published to npm (it landed earlier today), `npm install` resolves the new version cleanly. Lockfile entry now records: node_modules/@cryptohopper/sdk: 0.4.0-alpha.2 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Pim Feltkamp <pimfeltkamp@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Critical bug: every authenticated request currently fails. The transport sends
Authorization: Bearer <token>, which the AWS API Gateway in front ofapi.cryptohopper.com/v1/*rejects (it routesAuthorizationto a SigV4 parser and returns405 Missing Authentication Token).Cryptohopper's Public API v1 uses
access-token: <token>. Switching the SDK to send that header instead.Why this slipped through
cryptohopper-resources/docs/api/authentication.mdandgetting-started.mdsay "Authorization: Bearer" — they're wrong; the live docs at https://www.cryptohopper.com/api-documentation/how-the-api-works are authoritative ("access-token - Your access token received with the Oauth2 authentication").createMockFetch), so the wrong header never hit a real gateway.Confirmation from prior art
access-tokencryptohopper-ios-sdkHopperAPIRequest.swift:248access-token(for v1 calls;Beareronly for the V2 admin API)cryptohopper-android-sdkHopperAPIRequest.kt:331access-token(same v1/v2 split)code-samples/curl/README.md-H "access-token: [ACCESS TOKEN]"Changes
Authorization: Bearer ${this.apiKey}→"access-token": this.apiKey. Comment explains why.access-tokenheader is set andauthorizationis unset.CHANGELOG.md—0.4.0-alpha.2entry under "Fixed" with full root-cause writeup.src/version.ts+package.jsonbumped to0.4.0-alpha.2.Compatibility
No public-API change. The fix is purely in the request-builder. Every consumer call (
client.user.get(),client.hoppers.list(), etc.) keeps its existing signature and behaviour. Only the wire-level header changes.Test plan
npm test— 67/67 pass (was 67/67 before).npm run typecheck— clean.npm run build— clean.CRYPTOHOPPER_TOKEN=<real-token> npx tsx examples/whoami.tsshould now succeed where it would have 405'd before.Cross-reference