Add new swift account type to grid #119
Conversation
📝 WalkthroughWalkthroughThe pull request adds comprehensive Swift account support across OpenAPI schemas by introducing three new schema definitions (SwiftAccountInfo, PaymentSwiftAccountInfo, SwiftAccountExternalAccountInfo) and updating existing discriminators and enums to recognize SWIFT_ACCOUNT as a valid account type in both payment and external account flows. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Greptile SummaryThis PR adds support for SWIFT bank accounts as a new payment and external account type in the Grid API. The implementation follows the existing pattern for other account types (IBAN, NGN, UPI, etc.) by creating three schema files: Key changes:
Issue found: Confidence Score: 3/5
Important Files Changed
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -1,4 +1,4 @@ | |||
| allOf: | |||
| allOf: | |||
There was a problem hiding this comment.
syntax: incorrect indentation - this line should start at column 0, not with 2 spaces
| allOf: | |
| allOf: |
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 AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountCreateRequest.yaml
Line: 1:1
Comment:
**syntax:** incorrect indentation - this line should start at column 0, not with 2 spaces
```suggestion
allOf:
```
<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.![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
mintlify/openapi.yaml (1)
4684-4699: AddPaymentSwiftAccountInfotoPaymentInstructions.accountOrWalletInfoor remove SWIFT_ACCOUNT from the discriminator.The
PaymentAccountOrWalletInfodiscriminator includes SWIFT_ACCOUNT, butPaymentInstructions.accountOrWalletInfouses aoneOfthat does not referencePaymentSwiftAccountInfo. This means SWIFT payment instructions cannot be returned through the API, creating an inconsistency between the two schemas.openapi.yaml (1)
5106-5155: Blocker:PaymentInstructions.accountOrWalletInfodoesn’t allowSWIFT_ACCOUNT.
You addedSWIFT_ACCOUNTtoPaymentAccountOrWalletInfo+BankAccountOrWalletType, butPaymentInstructionscan’t represent it (missing inoneOf+ discriminator mapping). This will cause schema validation/codegen issues for any endpoint returning Swift payment instructions.Proposed fix (add SWIFT_ACCOUNT to PaymentInstructions)
accountOrWalletInfo: oneOf: @@ - title: Base Wallet $ref: '#/components/schemas/PaymentBaseWalletInfo' + - title: SWIFT Account + $ref: '#/components/schemas/PaymentSwiftAccountInfo' discriminator: propertyName: accountType mapping: @@ POLYGON_WALLET: '#/components/schemas/PaymentPolygonWalletInfo' BASE_WALLET: '#/components/schemas/PaymentBaseWalletInfo' + SWIFT_ACCOUNT: '#/components/schemas/PaymentSwiftAccountInfo'
🤖 Fix all issues with AI agents
In `@openapi/components/schemas/common/PaymentSwiftAccountInfo.yaml`:
- Around line 1-12: The PaymentSwiftAccountInfo schema places required and
properties alongside allOf instead of merging them; move the required and
properties into a third object inside allOf so the composed schemas (the $refs
to PaymentAccountOrWalletInfo and SwiftAccountInfo) are extended properly by an
object that declares the reference property and its requirement; update the
allOf array in PaymentSwiftAccountInfo.yaml to include that new object
containing the reference property and required:["reference"].
In
`@openapi/components/schemas/external_accounts/ExternalAccountCreateRequest.yaml`:
- Line 1: The YAML schema file ExternalAccountCreateRequest.yaml has leading
whitespace before the root key "allOf", causing it to be nested instead of a
top-level declaration; update the file so "allOf:" starts at column 0 (no
leading spaces) and re-indent the subsequent lines accordingly to maintain valid
YAML/OpenAPI structure, then run a YAML/OpenAPI validator to confirm the schema
parses correctly.
🧹 Nitpick comments (4)
openapi/components/schemas/common/SwiftAccountInfo.yaml (1)
1-24: Consider validatingswiftBicwith a pattern (and confirm whether it should be required).
Length-only checks allow many invalid values; if your system expects ISO 9362 BIC formatting, add a regex. Also confirm whether SWIFT routing requires BIC in practice (if yes, make it required).Proposed schema tightening (optional)
properties: swiftBic: type: string description: SWIFT/BIC code (8 or 11 characters). Recommended for international transfers. example: DBSASG2X minLength: 8 maxLength: 11 + # ISO 9362 (common validation): 4 letters bank + 2 letters country + 2 alnum location + optional 3 alnum branch + pattern: '^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$'mintlify/openapi.yaml (2)
4883-4920: Swift payment/account schemas look consistent with existingallOfcomposition.
Small drift risk: these inline schema definitions need to stay in sync withopenapi/components/schemas/common/SwiftAccountInfo.yaml. If mintlify/openapi.yaml is not generated, consider referencing shared components instead of duplicating.
5396-5416:SwiftAccountExternalAccountInfowiring is consistent with other external account schemas.
Same note as above: avoid drift between this inline version and the componentizedSwiftAccountExternalAccountInfo.yamlused elsewhere.openapi.yaml (1)
4883-4920: Tighten validation forSwiftAccountInfo.swiftBic(optional but high-signal).
Right now it’s only length-bounded; consider adding a BIC/SWIFT format regex (and optionallyminLength: 1foraccountNumberto prevent empty strings).
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
mintlify/openapi.yamlopenapi.yamlopenapi/components/schemas/common/BankAccountOrWalletType.yamlopenapi/components/schemas/common/PaymentAccountOrWalletInfo.yamlopenapi/components/schemas/common/PaymentSwiftAccountInfo.yamlopenapi/components/schemas/common/SwiftAccountInfo.yamlopenapi/components/schemas/external_accounts/ExternalAccountCreateRequest.yamlopenapi/components/schemas/external_accounts/ExternalAccountInfo.yamlopenapi/components/schemas/external_accounts/SwiftAccountExternalAccountInfo.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Greptile Review
🔇 Additional comments (10)
openapi/components/schemas/common/BankAccountOrWalletType.yaml (1)
10-10: LGTM!The
SWIFT_ACCOUNTenum value follows the established naming convention and integrates correctly with the existing account type enumeration.openapi/components/schemas/common/PaymentAccountOrWalletInfo.yaml (1)
17-17: LGTM!The discriminator mapping for
SWIFT_ACCOUNTis correctly added and references the newPaymentSwiftAccountInfo.yamlschema introduced in this PR.openapi/components/schemas/external_accounts/SwiftAccountExternalAccountInfo.yaml (1)
1-19: Schema structure is correct and follows external account patterns.The composition with
SwiftAccountInfoand theaccountTypeenum constraint properly define the discriminator value. Thebeneficiaryfield withoneOfdiscriminator is properly configured for the two beneficiary types.The
referencefield present inPaymentSwiftAccountInfois not needed here—it's specific to payment flows. External account schemas (IbanAccountExternalAccountInfo,UsAccountExternalAccountInfo) intentionally omit it, and this schema correctly follows that pattern.mintlify/openapi.yaml (2)
5054-5055: Enum expansion looks good; verify downstream validators/SDK generators handle the new value.
Adding a new enum value can break strict client-side decoders if they don’t allow unknown values.
5530-5533: ExternalAccountInfo includes SWIFT in bothoneOfand discriminator mapping—LGTM.
This should make SWIFT accounts round-trip correctly through polymorphic decoding.openapi/components/schemas/external_accounts/ExternalAccountInfo.yaml (1)
14-15: SWIFT Account integration verified: schema file exists and is properly bundled.The referenced
SwiftAccountExternalAccountInfo.yamlfile exists at the expected location and is correctly integrated into both theoneOfarray (line 15) and the discriminator mapping (line 37) with consistent relative paths. This follows the established pattern used for other account types.openapi.yaml (4)
4676-4699: Good:PaymentAccountOrWalletInfodiscriminator mapping extended forSWIFT_ACCOUNT.
This is the right place to wire inPaymentSwiftAccountInfo.
5044-5061: AddingSWIFT_ACCOUNTtoBankAccountOrWalletTypemay break strict clients—verify versioning expectations.
If clients codegen enums and fail on unknown values, you may want to bump the API version/date (or clearly document “enums are extensible”).
5396-5417:SwiftAccountExternalAccountInfolooks consistent with other external-account variants.
Minor: you’re redundantly re-declaringaccountType(already constrained bySwiftAccountInfo); that’s fine for consistency with other*ExternalAccountInfoschemas.
5517-5560: Good:ExternalAccountInfooneOf+ discriminator mapping updated forSWIFT_ACCOUNT.
This completes the external-account polymorphism wiring.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| allOf: | ||
| - $ref: ./PaymentAccountOrWalletInfo.yaml | ||
| - $ref: ./SwiftAccountInfo.yaml | ||
| required: | ||
| - reference | ||
| properties: | ||
| reference: | ||
| type: string | ||
| description: >- | ||
| Unique reference code that must be included with the payment to properly | ||
| credit it | ||
| example: UMA-Q12345-REF |
There was a problem hiding this comment.
Schema structure issue: required and properties should be inside allOf.
The required and properties blocks are siblings of allOf rather than part of the composition. In OpenAPI 3.x, this structure may not correctly merge the additional reference field with the composed schemas. To properly extend the composed schemas with additional fields, wrap them in a third object within allOf.
Proposed fix
allOf:
- $ref: ./PaymentAccountOrWalletInfo.yaml
- $ref: ./SwiftAccountInfo.yaml
-required:
- - reference
-properties:
- reference:
- type: string
- description: >-
- Unique reference code that must be included with the payment to properly
- credit it
- example: UMA-Q12345-REF
+ - type: object
+ required:
+ - reference
+ properties:
+ reference:
+ type: string
+ description: >-
+ Unique reference code that must be included with the payment to properly
+ credit it
+ example: UMA-Q12345-REF📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| allOf: | |
| - $ref: ./PaymentAccountOrWalletInfo.yaml | |
| - $ref: ./SwiftAccountInfo.yaml | |
| required: | |
| - reference | |
| properties: | |
| reference: | |
| type: string | |
| description: >- | |
| Unique reference code that must be included with the payment to properly | |
| credit it | |
| example: UMA-Q12345-REF | |
| allOf: | |
| - $ref: ./PaymentAccountOrWalletInfo.yaml | |
| - $ref: ./SwiftAccountInfo.yaml | |
| - type: object | |
| required: | |
| - reference | |
| properties: | |
| reference: | |
| type: string | |
| description: >- | |
| Unique reference code that must be included with the payment to properly | |
| credit it | |
| example: UMA-Q12345-REF |
🤖 Prompt for AI Agents
In `@openapi/components/schemas/common/PaymentSwiftAccountInfo.yaml` around lines
1 - 12, The PaymentSwiftAccountInfo schema places required and properties
alongside allOf instead of merging them; move the required and properties into a
third object inside allOf so the composed schemas (the $refs to
PaymentAccountOrWalletInfo and SwiftAccountInfo) are extended properly by an
object that declares the reference property and its requirement; update the
allOf array in PaymentSwiftAccountInfo.yaml to include that new object
containing the reference property and required:["reference"].
| @@ -1,4 +1,4 @@ | |||
| allOf: | |||
| allOf: | |||
There was a problem hiding this comment.
Invalid YAML structure: root-level indentation.
The allOf: directive at line 1 has leading whitespace, which makes it a nested element rather than a root-level declaration. This will likely cause YAML parsing errors or unexpected schema behavior since OpenAPI expects the schema definition to start at column 0.
Proposed fix
- allOf:
+allOf:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| allOf: | |
| allOf: |
🤖 Prompt for AI Agents
In
`@openapi/components/schemas/external_accounts/ExternalAccountCreateRequest.yaml`
at line 1, The YAML schema file ExternalAccountCreateRequest.yaml has leading
whitespace before the root key "allOf", causing it to be nested instead of a
top-level declaration; update the file so "allOf:" starts at column 0 (no
leading spaces) and re-indent the subsequent lines accordingly to maintain valid
YAML/OpenAPI structure, then run a YAML/OpenAPI validator to confirm the schema
parses correctly.
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.