Uh oh!
There was an error while loading. Please reload this page.
chore: Sync account schemas - #353
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-pythonstudio · code · diff
✅ grid-openapistudio · code · diff
✅ grid-typescriptstudio · code · diff
✅ grid-kotlinstudio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThis PR syncs auto-generated account schemas from sparkcore VASP adapter definitions, adding support for ~15 new currency corridors (AED, BDT, BWP, COP, EGP, GHS, GTQ, HTG, JMD, MWK, MYR, PKR, RWF, SGD, THB, VND, etc.) and flattening the previous
Confidence Score: 4/5Safe to merge once the UsdAccountInfo breaking-change additions are confirmed intentional by the sparkcore team. One P1 finding:
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/common/UsdAccountInfo.yaml | Flattened from allOf pattern; adds bankName and phoneNumber as new required fields (breaking change) and adds MOBILE_MONEY to paymentRails enum (unusual for USD) |
| openapi/components/schemas/common/AedAccountInfo.yaml | New AED schema with IBAN and SWIFT fields; clean structure with proper regex validation |
| openapi/components/schemas/common/GhsAccountInfo.yaml | New GHS schema supporting both BANK_TRANSFER and MOBILE_MONEY rails; requires bankName, accountNumber, and phoneNumber |
| openapi/components/schemas/common/KesAccountInfo.yaml | New KES mobile money schema; phone number constrained to Kenyan prefix (+254) with 9-digit suffix |
| openapi/components/schemas/common/KesBeneficiary.yaml | New beneficiary schema (one of several identical INDIVIDUAL beneficiary schemas added in this PR) |
| openapi/components/schemas/common/PaymentInstructions.yaml | New currencies added to oneOf list and discriminator mapping; all new entries have matching discriminator keys |
| mintlify/openapi.yaml | Bundled spec updated to reflect all schema changes including the flattening, new currencies, and the UsdAccountInfo breaking-change additions |
| openapi/components/schemas/common/MxnAccountInfo.yaml | Flattened from allOf pattern; no new required fields, only structural simplification |
| openapi/components/schemas/common/BwpBeneficiary.yaml | New beneficiary schema, identical structure to all other new *Beneficiary files (INDIVIDUAL type only) |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
PI[PaymentInstructions.yaml\noneOf + discriminator] --> USD[PaymentUsdAccountInfo]
PI --> MXN[PaymentMxnAccountInfo]
PI --> EUR[PaymentEurAccountInfo]
PI --> GBP[PaymentGbpAccountInfo]
PI --> NGN[PaymentNgnAccountInfo]
PI --> KES[PaymentKesAccountInfo]
PI --> NEW["New Corridors\nAED, BDT, BWP, COP, EGP\nGHS, GTQ, HTG, JMD, MWK\nMYR, PKR, RWF, SGD, THB, VND\nXAF, ZAR, ZMW ..."]
USD -->|allOf| UsdBase[UsdAccountInfo\n⚠️ bankName + phoneNumber\nnow REQUIRED]
MXN -->|allOf| MxnBase[MxnAccountInfo\nflattened]
KES -->|allOf| KesBase[KesAccountInfo\n+254 phone regex]
KES -.->|beneficiary| KesBen[KesBeneficiary\nINDIVIDUAL only]
NGN -.->|beneficiary| NgnBen[NgnBeneficiary\nINDIVIDUAL only]
NEW -.->|beneficiary| NewBen["*Beneficiary schemas\n(BWP/MWK/RWF/TZS/UGX\nXAF/XOF/ZAR/ZMW)\nall identical structure"]
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfo.yaml
Line: 1-8
Comment:
**Breaking change: `bankName` and `phoneNumber` now required**`bankName` and `phoneNumber` have been added to the `required` list of `UsdAccountInfo`. Previously only `accountType`, `paymentRails`, `accountNumber`, and `routingNumber` were required. Any existing API consumer that constructs or validates a `UsdAccountInfo` payload without these two fields will now fail schema validation.
Additionally, `phoneNumber` in a USD bank account context (ACH / WIRE / RTP / FedNow) is unusual — it makes sense for the `MOBILE_MONEY` rail but not for the standard domestic banking rails. If `phoneNumber` is only needed when the payment rail is `MOBILE_MONEY`, consider making it conditionally required (e.g., via `if/then` in JSON Schema) rather than unconditionally required.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfo.yaml
Line: 17-24
Comment:
**`MOBILE_MONEY` rail in USD schema is unexpected**`MOBILE_MONEY` is included in the `paymentRails` enum for `UsdAccountInfo`. USD transfers are typically ACH, WIRE, RTP, or FedNow — `MOBILE_MONEY` is primarily associated with African/Asian mobile payment networks. If this is intentional (e.g., for a specific USD-denominated mobile money corridor), it may be worth adding a comment or description to clarify the use case so API consumers understand when to set this value.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "chore: Sync account schemas" | Re-trigger Greptile
| type: object | ||
| required: | ||
| - accountType | ||
| - paymentRails | ||
| - accountNumber | ||
| - routingNumber | ||
| - bankName | ||
| - phoneNumber |
There was a problem hiding this comment.
bankName and phoneNumber now required
bankName and phoneNumber have been added to the required list of UsdAccountInfo. Previously only accountType, paymentRails, accountNumber, and routingNumber were required. Any existing API consumer that constructs or validates a UsdAccountInfo payload without these two fields will now fail schema validation.
Additionally, phoneNumber in a USD bank account context (ACH / WIRE / RTP / FedNow) is unusual — it makes sense for the MOBILE_MONEY rail but not for the standard domestic banking rails. If phoneNumber is only needed when the payment rail is MOBILE_MONEY, consider making it conditionally required (e.g., via if/then in JSON Schema) rather than unconditionally required.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfo.yaml
Line: 1-8
Comment:
**Breaking change: `bankName` and `phoneNumber` now required**`bankName` and `phoneNumber` have been added to the `required` list of `UsdAccountInfo`. Previously only `accountType`, `paymentRails`, `accountNumber`, and `routingNumber` were required. Any existing API consumer that constructs or validates a `UsdAccountInfo` payload without these two fields will now fail schema validation.
Additionally, `phoneNumber` in a USD bank account context (ACH / WIRE / RTP / FedNow) is unusual — it makes sense for the `MOBILE_MONEY` rail but not for the standard domestic banking rails. If `phoneNumber` is only needed when the payment rail is `MOBILE_MONEY`, consider making it conditionally required (e.g., via `if/then` in JSON Schema) rather than unconditionally required.
How can I resolve this? If you propose a fix, please make it concise.
| type: string | ||
| enum: | ||
| - ACH | ||
| - WIRE | ||
| - RTP | ||
| - FEDNOW | ||
| - BANK_TRANSFER | ||
| - MOBILE_MONEY |
There was a problem hiding this comment.
MOBILE_MONEY rail in USD schema is unexpected
MOBILE_MONEY is included in the paymentRails enum for UsdAccountInfo. USD transfers are typically ACH, WIRE, RTP, or FedNow — MOBILE_MONEY is primarily associated with African/Asian mobile payment networks. If this is intentional (e.g., for a specific USD-denominated mobile money corridor), it may be worth adding a comment or description to clarify the use case so API consumers understand when to set this value.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfo.yaml
Line: 17-24
Comment:
**`MOBILE_MONEY` rail in USD schema is unexpected**`MOBILE_MONEY` is included in the `paymentRails` enum for `UsdAccountInfo`. USD transfers are typically ACH, WIRE, RTP, or FedNow — `MOBILE_MONEY` is primarily associated with African/Asian mobile payment networks. If this is intentional (e.g., for a specific USD-denominated mobile money corridor), it may be worth adding a comment or description to clarify the use case so API consumers understand when to set this value.
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!
Superseded by #374 |
Auto-synced account schemas.
These schemas are generated from VASP adapter field definitions in sparkcore.
Synced schemas:
common/— per-currency account info, beneficiary, and payment account schemascommon/PaymentInstructions.yaml— payment instructions oneOf (new currencies added)external_accounts/— per-currency external account schemas (reference common/)Please review the changes before merging.