Conversation
✱ Stainless preview buildsThis PR will update the Edit this comment to update it. It will appear in the SDK's changelogs. ✅ grid-openapi studio · code · diff
❗ grid-typescript studio
⏳ These are partial results; builds are still running. This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile OverviewGreptile SummaryAdded a new GET Key changes:
Critical issue identified: Confidence Score: 3/5
|
| Filename | Overview |
|---|---|
| openapi/paths/exchange-rates/exchange_rates.yaml | New GET /exchange-rates endpoint added with query parameters for filtering cached FX rates; has contradictory parameter requirements and example math errors |
| openapi/components/schemas/exchange_rates/ExchangeRate.yaml | New schema for exchange rate responses; has inconsistent exchangeRate description compared to Quote schema and missing required fields |
| openapi/components/schemas/exchange_rates/ExchangeRateFees.yaml | Fee structure schema with fixed fee field; no required fields defined which allows empty objects |
| openapi/components/schemas/common/LightningInfo.yaml | New shared schema extracted from LightningExternalAccountInfo for reusability; schema description claims mutual exclusivity but doesn't enforce it |
Sequence Diagram
sequenceDiagram
participant Client
participant API as Grid API
participant Cache as FX Rate Cache
participant Platform as Platform Config
Note over Client,Platform: Exchange Rates Flow
Client->>API: GET /exchange-rates?sourceCurrency=USD
activate API
API->>Platform: Get platform-specific fees
activate Platform
Platform-->>API: Fee configuration
deactivate Platform
API->>Cache: Query cached rates (USD -> *)
activate Cache
Note over Cache: Rates cached ~5 minutes
Cache-->>API: Available corridors with rates
deactivate Cache
API->>API: Apply platform fees to rates
API->>API: Calculate receiving amounts<br/>(if sendingAmount provided)
API-->>Client: 200 OK: Array of ExchangeRate objects
deactivate API
Note over Client,API: Client can then use rates to create quotes
Client->>API: POST /quotes (using rate info)
API-->>Client: Quote with locked rate
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
from
8f92946 to
3fecd5a
Compare
Additional Comments (1)
Per Prompt To Fix With AIThis is a comment left during a code review.
Path: openapi.yaml
Line: 4113:4115
Comment:
**Generated file edited**
Per `CLAUDE.md`, `openapi.yaml` at repo root is a bundled artifact and should not be edited manually; changes should be made in `openapi/**` and then bundled (which also updates `mintlify/openapi.yaml`). Editing the generated file directly will be overwritten on the next build and can drift from the split source of truth.
How can I resolve this? If you propose a fix, please make it concise. |
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
2 times, most recently
from
5c32c0c to
c80209d
Compare
Additional Comments (2)
Prompt To Fix With AIThis is a comment left during a code review.
Path: openapi.yaml
Line: 1:3
Comment:
**Generated spec edited directly**
Per `CLAUDE.md`, the repo-root `openapi.yaml` is a bundled artifact generated from `openapi/**` via `npm run build:openapi`. Editing it directly will be overwritten and can drift from the split spec. The fix is to update only the split spec under `openapi/**` and re-bundle so this file is produced by the build.
How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix With AIThis is a comment left during a code review.
Path: mintlify/openapi.yaml
Line: 1:3
Comment:
**Generated spec edited directly**
`mintlify/openapi.yaml` is also a bundled copy of the OpenAPI spec and will be overwritten when the spec is rebuilt. Changes should be made in the split spec under `openapi/**` and then re-bundled, rather than editing this file by hand.
How can I resolve this? If you propose a fix, please make it concise. |
Additional Comments (1)
Prompt To Fix With AIThis is a comment left during a code review.
Path: .github/workflows/stainless-action.yml
Line: 34:41
Comment:
**Inconsistent Stainless config detection**
`guess_config: true` is set for the preview job but not for the merge job. If Stainless needs config guessing for this repo, merge builds can fail even when preview builds pass. Either add `guess_config: true` to the merge step as well, or remove it from preview if it’s not required.
How can I resolve this? If you propose a fix, please make it concise. |
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
from
c80209d to
0527518
Compare
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
from
0527518 to
9d4e3c1
Compare
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| decimals: 2 | ||
| name: US Dollar | ||
| symbol: "$" | ||
| sourcePaymentRail: RTP | ||
| sendingAmount: 10000 | ||
| destinationCurrency: | ||
| code: INR | ||
| decimals: 2 | ||
| name: Indian Rupee | ||
| symbol: "₹" | ||
| destinationPaymentRail: UPI | ||
| receivingAmount: 1650000 | ||
| exchangeRate: 82.50 | ||
| fees: | ||
| fixed: 100 | ||
| updatedAt: "2025-02-05T12:00:00Z" | ||
| - sourceCurrency: | ||
| code: USD | ||
| decimals: 2 | ||
| name: US Dollar | ||
| symbol: "$" | ||
| sourcePaymentRail: RTP | ||
| sendingAmount: 10000 | ||
| destinationCurrency: | ||
| code: EUR | ||
| decimals: 2 | ||
| name: Euro | ||
| symbol: "€" | ||
| destinationPaymentRail: SEPA_INSTANT | ||
| receivingAmount: 18500 | ||
| exchangeRate: 0.925 | ||
| fees: | ||
| fixed: 10 | ||
| updatedAt: "2025-02-05T12:00:00Z" | ||
| "400": | ||
| description: Bad request - Invalid parameters | ||
| content: |
There was a problem hiding this comment.
Example values don't match schema calculations
The example response shows mathematically inconsistent values:
USD to INR example:
- Sending: 10000 cents (100 USD)
- Rate: 82.5 (per description: "82.5 INR per 1 USD")
- Fees: 100 cents (1 USD)
- Receiving: 1650000 paise (16500 INR) ❌
Expected calculation: (10000 - 100) * 82.5 / 100 = 8167.5 INR or 10000 * 82.5 / 100 = 8250 INR
USD to EUR example:
- Sending: 10000 cents (100 USD)
- Rate: 0.925
- Receiving: 18500 cents (185 EUR) ❌
Expected: 10000 * 0.925 = 9250 cents (92.5 EUR)
The receivingAmount values appear to be approximately 2x what the exchangeRate suggests. Please verify the calculation logic or correct the examples to match the actual API behavior.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/paths/exchange-rates/exchange_rates.yaml
Line: 71:107
Comment:
**Example values don't match schema calculations**
The example response shows mathematically inconsistent values:
**USD to INR example:**
- Sending: 10000 cents (100 USD)
- Rate: 82.5 (per description: "82.5 INR per 1 USD")
- Fees: 100 cents (1 USD)
- Receiving: 1650000 paise (16500 INR) ❌
Expected calculation: `(10000 - 100) * 82.5 / 100 = 8167.5 INR` or `10000 * 82.5 / 100 = 8250 INR`
**USD to EUR example:**
- Sending: 10000 cents (100 USD)
- Rate: 0.925
- Receiving: 18500 cents (185 EUR) ❌
Expected: `10000 * 0.925 = 9250 cents (92.5 EUR)`
The receivingAmount values appear to be approximately 2x what the exchangeRate suggests. Please verify the calculation logic or correct the examples to match the actual API behavior.
How can I resolve this? If you propose a fix, please make it concise.| required: false | ||
| schema: | ||
| type: integer | ||
| format: int64 | ||
| minimum: 0 | ||
| default: 10000 | ||
| example: 10000 | ||
| responses: | ||
| "200": | ||
| description: Successful operation |
There was a problem hiding this comment.
Query parameter default value without proper documentation
The sendingAmount parameter has default: 10000 in the schema, but OpenAPI 3.1 default values for query parameters don't automatically get applied by clients - they're documentation-only.
The description should clarify what happens when this parameter is omitted:
- Does the server use 10000 as the default?
- Does it return rates without calculated receiving amounts?
- Does it return an error?
| required: false | |
| schema: | |
| type: integer | |
| format: int64 | |
| minimum: 0 | |
| default: 10000 | |
| example: 10000 | |
| responses: | |
| "200": | |
| description: Successful operation | |
| description: Sending amount in the smallest unit of the source currency (e.g., cents for USD). If not provided, rates are returned with a default calculation based on 10000 units (e.g., 100.00 in major currency). |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/paths/exchange-rates/exchange_rates.yaml
Line: 42:51
Comment:
**Query parameter `default` value without proper documentation**
The `sendingAmount` parameter has `default: 10000` in the schema, but OpenAPI 3.1 default values for query parameters don't automatically get applied by clients - they're documentation-only.
The description should clarify what happens when this parameter is omitted:
- Does the server use 10000 as the default?
- Does it return rates without calculated receiving amounts?
- Does it return an error?
```suggestion
description: Sending amount in the smallest unit of the source currency (e.g., cents for USD). If not provided, rates are returned with a default calculation based on 10000 units (e.g., 100.00 in major currency).
```
How can I resolve this? If you propose a fix, please make it concise.| receivingAmount: 1650000 | ||
| exchangeRate: 82.50 | ||
| fees: | ||
| fixed: 100 | ||
| updatedAt: "2025-02-05T12:00:00Z" |
There was a problem hiding this comment.
Incorrect example math
In the 200-response example, sendingAmount: 10000 (=$100) and exchangeRate: 82.50 imply a receiving amount of 10000 * 82.5 = 825000 (in paise) before fees, but the example shows receivingAmount: 1650000 (double). This makes the example internally inconsistent and will mislead SDK/docs consumers. The EUR example below has the same issue (10000 * 0.925 = 9250, but example shows 18500).
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/paths/exchange-rates/exchange_rates.yaml
Line: 82:86
Comment:
**Incorrect example math**
In the 200-response example, `sendingAmount: 10000` (=$100) and `exchangeRate: 82.50` imply a receiving amount of `10000 * 82.5 = 825000` (in paise) before fees, but the example shows `receivingAmount: 1650000` (double). This makes the example internally inconsistent and will mislead SDK/docs consumers. The EUR example below has the same issue (`10000 * 0.925 = 9250`, but example shows `18500`).
How can I resolve this? If you propose a fix, please make it concise.
Additional Comments (3)
The Currency schema has no For SDK generator compatibility (especially Stainless which is configured in this PR), consider adding: required:
- code
- name
- symbol
- decimalsThis ensures generated SDKs properly validate Currency objects and prevents runtime errors from missing required fields. Prompt To Fix With AIThis is a comment left during a code review.
Path: openapi/components/schemas/common/Currency.yaml
Line: 1:23
Comment:
**Missing `required` fields in Currency schema**
The Currency schema has no `required` field list, which means SDK generators will treat all properties (code, name, symbol, decimals) as optional. However, all examples throughout the codebase populate all four fields, suggesting they should be required for consistent API behavior.
For SDK generator compatibility (especially Stainless which is configured in this PR), consider adding:
```yaml
required:
- code
- name
- symbol
- decimals
```
This ensures generated SDKs properly validate Currency objects and prevents runtime errors from missing required fields.
How can I resolve this? If you propose a fix, please make it concise.
The ExchangeRateFees schema only has one property ( Consider adding: required:
- fixedOr if Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time! Prompt To Fix With AIThis is a comment left during a code review.
Path: openapi/components/schemas/exchange_rates/ExchangeRateFees.yaml
Line: 1:10
Comment:
**Missing `required` field for ExchangeRateFees**
The ExchangeRateFees schema only has one property (`fixed`) but doesn't specify if it's required. Since fees are a required part of ExchangeRate (line 9 of ExchangeRate.yaml), and the schema is specifically for "fees associated with an exchange rate", the `fixed` field should likely be required.
Consider adding:
```yaml
required:
- fixed
```
Or if `fixed` fees are truly optional (e.g., when only variable fees apply), add documentation explaining when this field may be absent.
<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>
How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix With AIThis is a comment left during a code review.
Path: openapi/components/schemas/common/Currency.yaml
Line: 1:3
Comment:
**All fields optional in SDKs**
`Currency` doesn’t declare a `required:` list, so code generators will treat `code/name/symbol/decimals` as optional even though your examples (and typical currency objects) always include them. If these fields are always present in API responses, mark them as required to avoid generating weaker/incorrect SDK types.
How can I resolve this? If you propose a fix, please make it concise. |
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
from
9d4e3c1 to
cd71b37
Compare
| type: object | ||
| description: > | ||
| Lightning payment destination. Exactly one of `invoice`, `bolt12`, or `lightningAddress` must be provided. |
There was a problem hiding this comment.
Schema contradicts description
This schema claims “Exactly one of invoice, bolt12, or lightningAddress must be provided”, but it doesn’t express that constraint (no oneOf/anyOf + required sets, and no not to prevent multiple). As a result, the contract allows none of them or multiple at once, which conflicts with the documented behavior and will generate incorrect SDK types/validation.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/LightningInfo.yaml
Line: 1:3
Comment:
**Schema contradicts description**
This schema claims “Exactly one of `invoice`, `bolt12`, or `lightningAddress` must be provided”, but it doesn’t express that constraint (no `oneOf`/`anyOf` + `required` sets, and no `not` to prevent multiple). As a result, the contract allows none of them or multiple at once, which conflicts with the documented behavior and will generate incorrect SDK types/validation.
How can I resolve this? If you propose a fix, please make it concise.
pengying
force-pushed
the
02-05-feat_adding_openapi_schema_for_fx_api
branch
from
cd71b37 to
c2ce904
Compare
| example: 1650000 | ||
| exchangeRate: | ||
| type: number | ||
| description: Number of destination currency units per sending currency unit |
There was a problem hiding this comment.
exchangeRate description conflicts with Quote schema (Quote.yaml line 70). ExchangeRate says "destination per sending" but Quote says "sending per receiving" - these are mathematical inverses. The calculation examples in exchange_rates.yaml also don't match either definition, making it unclear which is correct.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/exchange_rates/ExchangeRate.yaml
Line: 38:38
Comment:
`exchangeRate` description conflicts with Quote schema (Quote.yaml line 70). ExchangeRate says "destination per sending" but Quote says "sending per receiving" - these are mathematical inverses. The calculation examples in `exchange_rates.yaml` also don't match either definition, making it unclear which is correct.
How can I resolve this? If you propose a fix, please make it concise.3 participants
TL;DR
Added new Exchange Rates API endpoint to retrieve cached foreign exchange rates with platform-specific fees.
What changed?
/exchange-ratesendpoint that provides cached FX ratesExchangeRate- Contains source/destination currency details, payment rails, amounts, rates, and feesExchangeRateFees- Defines fee structure for exchange ratesCurrencyschema definition to avoid duplicationsourceCurrency(required)destinationCurrency(optional, can specify multiple)sendingAmount(optional)GET request to
/exchange-rateswith the requiredsourceCurrencyparameter:Optional parameters:
&destinationCurrency=INR&destinationCurrency=GBP&sendingAmount=20000