feat(spec): add sender-denominated bounds to receiver lookup CurrencyPreference

[ls-bolt]

Summary

GET /exchange-rates reports its bounds as minSendingAmount/maxSendingAmount in the sender's currency, but the receiver lookup endpoints report min/max in the receiver's currency. Integrators that need both sides end up recomputing the sending-side bound client-side, which they cannot do correctly — the real sending bound is the intersection of an FX-converted receiver cap and a sending-leg cap the client never sees.

This adds the sender-denominated pair to CurrencyPreference, matching the semantics /exchange-rates already uses.

Approach

Purely additive and optional. CurrencyPreference is shared by ReceiverUmaLookupResponse and ReceiverExternalAccountLookupResponse (both allOf ReceiverLookupResponse), so one schema change covers both lookup endpoints.

Existing min/max are unchanged and stay required. The new fields are optional so a server that cannot resolve the sending-side bound omits them rather than publishing a wrong number, and no existing client breaks.

Both descriptions carry the same "estimate, subject to change when calling the quotes endpoint" caveat that estimatedExchangeRate already documents — only POST /quotes produces a locked rate.

A sending-denominated integer is meaningless without naming its currency, so ReceiverLookupResponse also gains an optional sendingCurrency. /exchange-rates solves the same problem with sourceCurrency; the sender is identical for every entry in one lookup, so it belongs on the response rather than repeated on each CurrencyPreference. (Raised by Greptile — good catch.)

Changes: 4 files

• openapi/components/schemas/receiver/CurrencyPreference.yaml — add optional minSendingAmount / maxSendingAmount (int64, sender-currency minor units)
• openapi/components/schemas/receiver/ReceiverLookupResponse.yaml — add optional sendingCurrency so those minor units are interpretable
• openapi.yaml — rebundled (make build)
• mintlify/openapi.yaml — rebundled

npm run lint passes with 0 errors.

The sparkcore implementation that populates these fields is a separate PR in webdev.

Reply with a comment (e.g. LGTM) to approve — emoji reactions don't notify me here.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Grid	🟢 Ready	View Preview	Aug 26, 2026, 6:15 PM

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ignored	Preview	Aug 26, 2026 6:26pm
grid-wallet-demo	Ignored	Preview	Aug 26, 2026 6:26pm

[lightspark-bot]

• feat(spec): add sender-denominated bounds to receiver lookup CurrencyPreference #868 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

chore(internal): regenerate SDK with no functional changes

go

feat(api): add sending amount bounds to receiver supported currency response

kotlin

feat(api): add max/min sending amount fields to receiver lookup response

openapi

feat(api): add min/maxSendingAmount fields to currency limits

php

feat(api): add maxSendingAmount/minSendingAmount to receiver supported currency

python

feat(api): add max_sending_amount and min_sending_amount to SupportedCurrency

ruby

feat(api): add max_sending_amount and min_sending_amount fields to lookup response

typescript

feat(api): add maxSendingAmount/minSendingAmount to receiver lookup response

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-typescript studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ❗ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/8d053b221653d6845877ef7e7939c699aeac2f3d/dist.tar.gz

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-openapi studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-ruby studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ✅ → test ✅

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-go studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ❗ → test ❗

go get github.com/stainless-sdks/grid-go@cb818dad69e4d3ee2db4789eb870a08f2e5c4b6c

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ✅ → test ❗

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-python studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ❗ → test ❗

pip install https://pkg.stainless.com/s/grid-python/2bd3bd168bed28c836a81909adfbdfbf3b682114/grid-0.0.1-py3-none-any.whl

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-php studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → lint ✅ → test ✅

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

✅ grid-cli studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️ → build ❗ → lint ❗ → test ❗

New diagnostics (1 note)

💡 Schema/IsAmbiguous: Missing type for schema

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-08-26 18:35:22 UTC

[greptile-apps]

Greptile Summary

The PR adds optional sender-denominated minimum and maximum amounts to receiver lookup currency preferences and synchronizes both bundled specifications. The response contract currently omits the sender currency needed to interpret those minor-unit values.

Confidence Score: 4/5

The response contract should identify the sender currency before merging so clients can safely interpret the new minor-unit bounds.

Receiver lookups can return sender-denominated integer bounds without exposing the currency or decimal scale that gives those integers meaning, while the analogous exchange-rate representation includes sourceCurrency.

Files Needing Attention: openapi/components/schemas/receiver/CurrencyPreference.yaml

Important Files Changed

Filename	Overview
openapi/components/schemas/receiver/CurrencyPreference.yaml	Adds the two optional bounds, but their sender-currency denomination is not represented in the lookup response.
openapi.yaml	Correctly mirrors the source schema addition, including the same missing denomination context.
mintlify/openapi.yaml	Keeps the documentation bundle synchronized but propagates the ambiguous sender-denominated fields.

Prompt To Fix All With AI

### Issue 1
openapi/components/schemas/receiver/CurrencyPreference.yaml:30-41
**Sender currency is missing**

When a receiver lookup returns `minSendingAmount` or `maxSendingAmount`, the response does not identify the sender currency whose minor units define these values, causing clients to display or validate sending limits using the wrong denomination. The analogous exchange-rate response avoids this ambiguity by including `sourceCurrency` alongside its bounds.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat(spec): add sender-denominated bound..." | Re-trigger Greptile}

[greptile-apps]

Sender currency is missing

When a receiver lookup returns minSendingAmount or maxSendingAmount, the response does not identify the sender currency whose minor units define these values, causing clients to display or validate sending limits using the wrong denomination. The analogous exchange-rate response avoids this ambiguity by including sourceCurrency alongside its bounds.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/receiver/CurrencyPreference.yaml
Line: 30-41

Comment:
**Sender currency is missing**

When a receiver lookup returns `minSendingAmount` or `maxSendingAmount`, the response does not identify the sender currency whose minor units define these values, causing clients to display or validate sending limits using the wrong denomination. The analogous exchange-rate response avoids this ambiguity by including `sourceCurrency` alongside its bounds.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[ls-bolt]

Good catch — fixed. A sender-denominated integer isn't interpretable without naming its currency.

Added an optional sendingCurrency to ReceiverLookupResponse (the shared base for both the UMA and external-account lookups) rather than putting it on each CurrencyPreference: the sender is the same for every entry in one lookup, so repeating it per currency would invite the two from disagreeing. That mirrors how /exchange-rates carries sourceCurrency alongside its bounds.

---

🤖 astral-herald-2(#2) | Feedback