feat(transfers): allow selecting payment rail on transfer-out destination#533
feat(transfers): allow selecting payment rail on transfer-out destination#533pengying wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview builds for gridThis PR will update the cli csharp go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-typescript studio · code · diff
✅ grid-python studio · code · diff
✅ grid-csharp studio · code · diff
✅ grid-go studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThis PR introduces a dedicated
Confidence Score: 4/5Safe to merge — the change is additive (optional field only) and the shared ExternalAccountReference schema used elsewhere is left untouched. The new TransferOutDestination schema is minimal and correct. The only noteworthy item is a style inconsistency in how the paymentRail description is positioned relative to allOf compared to the identical field in AccountDestination.yaml, which won't affect runtime behavior but is worth aligning for doc-rendering consistency. openapi/components/schemas/transfers/TransferOutDestination.yaml — minor description placement inconsistency worth a quick look before merging.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/transfers/TransferOutDestination.yaml | New schema for transfer-out destination; paymentRail is optional and correctly references the shared PaymentRail enum, but description placement differs from the existing AccountDestination.yaml pattern. |
| openapi/components/schemas/transfers/TransferOutRequest.yaml | Switches destination ref from ExternalAccountReference to the new TransferOutDestination; the description sibling-to-$ref pattern was already present before this PR. |
| openapi/paths/transfers/transfer_out.yaml | Adds paymentRail: ACH to the request example — straightforward and consistent with the schema change. |
| openapi.yaml | Bundled output correctly reflecting the new TransferOutDestination schema and updated TransferOutRequest. |
| mintlify/openapi.yaml | Mintlify bundled output matches openapi.yaml changes; no divergence detected. |
Sequence Diagram
sequenceDiagram
participant Client
participant API as Grid API
participant Validator as Schema Validator
participant Rails as Payment Rail Selector
Client->>API: POST /transfers/transfer-out
Note over Client,API: { source: { accountId }, destination: { accountId, paymentRail? }, amount }
API->>Validator: Validate TransferOutRequest
Validator->>Validator: Check TransferOutDestination schema
alt paymentRail provided
Validator-->>API: Valid (e.g. paymentRail: ACH)
API->>Rails: Use specified rail
else paymentRail omitted
Validator-->>API: Valid (field optional)
API->>Rails: Select default rail for account
end
Rails-->>API: Rail confirmed
API-->>Client: 201 Created (transfer initiated)
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
openapi/components/schemas/transfers/TransferOutDestination.yaml:9-15
The `description` placement for `paymentRail` is inconsistent with the equivalent field in `AccountDestination.yaml`. There, the description lives **inside** the `allOf` array as a second schema object (`- description: ...`), while here it sits as a sibling to `allOf`. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.
```suggestion
paymentRail:
allOf:
- $ref: ../common/PaymentRail.yaml
- description: >-
The payment rail to use for the transfer. Must be one of the rails
supported by the destination account. If not specified, the system
will select a default rail.
```
Reviews (1): Last reviewed commit: "feat(transfers): allow selecting payment..." | Re-trigger Greptile
| paymentRail: | ||
| description: >- | ||
| The payment rail to use for the transfer. Must be one of the rails | ||
| supported by the destination account. If not specified, the system | ||
| will select a default rail. | ||
| allOf: | ||
| - $ref: ../common/PaymentRail.yaml |
There was a problem hiding this comment.
The
description placement for paymentRail is inconsistent with the equivalent field in AccountDestination.yaml. There, the description lives inside the allOf array as a second schema object (- description: ...), while here it sits as a sibling to allOf. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.
| paymentRail: | |
| description: >- | |
| The payment rail to use for the transfer. Must be one of the rails | |
| supported by the destination account. If not specified, the system | |
| will select a default rail. | |
| allOf: | |
| - $ref: ../common/PaymentRail.yaml | |
| paymentRail: | |
| allOf: | |
| - $ref: ../common/PaymentRail.yaml | |
| - description: >- | |
| The payment rail to use for the transfer. Must be one of the rails | |
| supported by the destination account. If not specified, the system | |
| will select a default rail. |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/transfers/TransferOutDestination.yaml
Line: 9-15
Comment:
The `description` placement for `paymentRail` is inconsistent with the equivalent field in `AccountDestination.yaml`. There, the description lives **inside** the `allOf` array as a second schema object (`- description: ...`), while here it sits as a sibling to `allOf`. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.
```suggestion
paymentRail:
allOf:
- $ref: ../common/PaymentRail.yaml
- description: >-
The payment rail to use for the transfer. Must be one of the rails
supported by the destination account. If not specified, the system
will select a default rail.
```
How can I resolve this? If you propose a fix, please make it concise.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!
…tion Add an optional `paymentRail` field to the transfer-out destination, mirroring the rail selection already available on quote destinations. Introduces a dedicated `ExternalAccountDestinationReference` schema (accountId + paymentRail) so the shared `ExternalAccountReference` used by transfer-in is left unchanged. The field reuses the common `PaymentRail` enum. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2fdb748 to
4088263
Compare

What
Adds an optional
paymentRailfield to the transfer-out destination, mirroring the rail selection already available on quote destinations.Changes
TransferOutDestinationschema (accountId+ optionalpaymentRail) — used only by transfer-out, so the sharedExternalAccountReference(transfer-in source) is left unchanged.TransferOutRequest.destinationnow references the new schema.paymentRailreuses the commonPaymentRailenum (ACH, SEPA, PIX, WIRE, …); when omitted, the system selects a default rail.paymentRail: ACHto the transfer-out request example.openapi.yaml+mintlify/openapi.yaml.Verification
make build+make lintpass with 0 errors.🤖 Generated with Claude Code