feat(ramps-controller): send client identity metadata headers on on-ramp API requests - #9983
feat(ramps-controller): send client identity metadata headers on on-ramp API requests#9983amitabh94 wants to merge 4 commits into
Conversation
…amp API requests Adds optional clientProduct / clientVersion / clientEnvironment constructor options to RampsService and TransakService. When provided by the host, every on-ramp API fetch carries x-metamask-clientproduct, x-metamask-clientversion, and x-metamask-clientenvironment so the API can evaluate version- and environment-gated feature flags per client. All fields are optional: older hosts send no headers and the API fails closed. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@metamaskbot publish-preview |
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
…cache correctness The on-ramp API sits behind a CDN whose cache key is the URL; headers alone would serve one client's cached response to another. Cacheable GETs now carry clientProduct / clientVersion / clientEnvironment in the query string as well. The API reads params first and falls back to the headers. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@metamaskbot publish-preview |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f42a461. Configure here.
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Version-only gating: RC-first rollout is expressed via minimumVersion (RC builds carry the next release version before the store rollout), so the environment dimension is unnecessary. Matches the product+version convention used by core-backend and the bridge status API. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@metamaskbot publish-preview |
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Headers duplicated the query params and risked server-side decisions keyed off values the CDN cache key cannot see. Identity now travels solely in the URL. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@metamaskbot publish-preview |
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |

Explanation
The on-ramp API is adding server-side feature flags (LaunchDarkly) that are gated per client product, client version, and client build environment — e.g. "enable feature X for MetaMask Mobile >= 7.60.0 RC builds only". To evaluate those gates, the API needs to know which client is calling.
This PR adds optional
clientProduct,clientVersion, andclientEnvironmentconstructor options toRampsServiceandTransakService. When the host supplies them, every on-ramp API fetch carries:x-metamask-clientproduct(e.g.metamask-mobile)x-metamask-clientversion(the app SemVer, not the ramps-controller package version)x-metamask-clientenvironment(RFFC-aligned build flavor:prod/rc/exp/dev)All fields are optional. Hosts that don't pass them send no identity headers, and the API fails closed (feature off) — so this is fully backwards compatible.
The
controllerquery param is intentionally left as the ramps-controller package version; the new headers carry the app identity instead of overloading it.References
Related to the on-ramp API version-gated feature flag rollout (Unified Buy 2.0 catalog gating / fiat soft-default).
Changelog
Updated
packages/ramps-controller/CHANGELOG.md(Unreleased → Added).Checklist
Made with Cursor