Open
Conversation
Contributor
Greptile SummaryThis PR auto-syncs account schemas generated from VASP adapter field definitions in sparkcore, adding support for 9 new currencies (AED, KES, MWK, RWF, TZS, UGX, XOF, ZAR, ZMW) across both Key changes:
Confidence Score: 2/5
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/common/AedAccountInfo.yaml | New AED account info schema with correct structure, but IBAN and SWIFT examples reference German bank identifiers instead of UAE-specific ones. |
| openapi/components/schemas/common/AedBeneficiary.yaml | New individual beneficiary schema for AED accounts; structure is consistent with other currency beneficiary schemas. |
| openapi/components/schemas/common/PaymentInstructions.yaml | Adds nine new payment currency discriminator entries (AED, KES, MWK, RWF, TZS, UGX, XOF, ZAR, ZMW); previously flagged issue with missing PaymentAccountType.yaml enum values remains open. |
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Adds AED external account to oneOf and discriminator mapping, but retains the erroneous LIGHTNING_ACCOUNT duplicate mapping (already flagged in a prior review thread). |
| openapi/components/schemas/common/GbpAccountInfo.yaml | Sort code pattern changed from accepting hyphenated format (XX-XX-XX) to digits-only (XXXXXX), which is a breaking change for consumers supplying sort codes with hyphens. |
| openapi/components/schemas/common/BrlAccountInfo.yaml | Adds validation constraints and a new lowercase-only pixKeyType enum; narrowing an unconstrained string field could break existing consumers using uppercase values. |
| openapi/components/schemas/common/DkkAccountInfo.yaml | Field renamed from swiftBic to swiftCode (breaking change, flagged in prior review thread); also adds IBAN/SWIFT validation patterns and examples. |
| openapi/components/schemas/common/EurAccountInfo.yaml | Same swiftBic→swiftCode rename as DkkAccountInfo.yaml; adds IBAN/SWIFT validation patterns consistent with other EUR-zone schemas. |
| openapi/components/schemas/external_accounts/AedExternalAccountInfo.yaml | New AED external account schema correctly composing BaseExternalAccountInfo, AedAccountInfo, and AedBeneficiary with a proper discriminator. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[PaymentInstructions / ExternalAccountInfoOneOf] -->|oneOf discriminator| B[Existing Currencies]
A -->|NEW: oneOf discriminator| C[New Currencies Added]
C --> AED[AED_ACCOUNT\nAedAccountInfo/AedExternalAccountInfo]
C --> KES[KES_ACCOUNT\nKesAccountInfo]
C --> MWK[MWK_ACCOUNT\nMwkAccountInfo]
C --> RWF[RWF_ACCOUNT\nRwfAccountInfo]
C --> TZS[TZS_ACCOUNT\nTzsAccountInfo]
C --> UGX[UGX_ACCOUNT\nUgxAccountInfo]
C --> XOF[XOF_ACCOUNT\nXofAccountInfo]
C --> ZAR[ZAR_ACCOUNT\nZarAccountInfo]
C --> ZMW[ZMW_ACCOUNT\nZmwAccountInfo]
AED --> AEDBen[AedBeneficiary\nINDIVIDUAL / BUSINESS]
style C fill:#d4f5d4,stroke:#4caf50
style AED fill:#d4f5d4,stroke:#4caf50
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/AedAccountInfo.yaml
Line: 19-23
Comment:
**Incorrect IBAN/SWIFT examples for AED account**
The `iban` example `DE89370400440532013000` is a German IBAN (prefix `DE`), not a UAE IBAN. UAE IBANs use the `AE` prefix and are 23 characters long (e.g., `AE070331234567890123456`). The same copy-paste issue affects the `swiftCode` example — `DEUTDEFF` is Deutsche Bank's BIC, not a UAE bank. These mismatched examples are in the schema for an **AED** (UAE Dirham) account and could mislead API consumers about the expected format.
```suggestion
description: The IBAN of the bank account
example: AE070331234567890123456
minLength: 15
maxLength: 34
pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```
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/AedAccountInfo.yaml
Line: 26-30
Comment:
**SWIFT example mismatch for AED account**
`DEUTDEFF` is Deutsche Bank's BIC (a German bank). For an AED (UAE Dirham) account, the example should reference a UAE-based bank, such as `EBILAEAD` (Emirates NBD) or similar.
```suggestion
description: The SWIFT/BIC code of the bank
example: EBILAEAD
minLength: 8
maxLength: 11
pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$
```
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/GbpAccountInfo.yaml
Line: 18-24
Comment:
**Breaking change: sort code hyphen format removed**
The previous pattern `'^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$'` accepted both hyphenated (`20-00-00`) and non-hyphenated (`200000`) sort codes. The new pattern `^[0-9]{6}$` only accepts the 6-digit format without hyphens.
Any existing API consumers who currently provide sort codes in the traditional `XX-XX-XX` format (which UK banks widely display) will now receive validation errors. If this normalization is intentional, it should be called out explicitly in the description, and consumers should be notified of the format change.
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/BrlAccountInfo.yaml
Line: 26-32
Comment:
**Potentially breaking: `pixKeyType` enum uses lowercase values**
A new `enum` constraint has been added to `pixKeyType` using lowercase values (`email`, `phone`, `cpf`, `cnpj`, `random`). If any existing API consumers are passing uppercase or mixed-case values (e.g., `EMAIL`, `CPF`, `PHONE`), they will now fail schema validation. This is a narrowing change on a previously unconstrained string field.
If uppercase or mixed-case variants were previously accepted by the backend, they should be included in the enum, or the description should make the casing requirement explicit.
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: 23509bc
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Show resolved
Hide resolved
JasonCWang
force-pushed
the
auto/sync-grid-schemas-20260316-212808
branch
from
10dec09 to
23509bc
Compare
Contributor
✱ 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-openapi studio · code · diff
✅ grid-python studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-typescript studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Comment on lines
18
to
+24
| sortCode: | ||
| type: string | ||
| description: UK bank sort code (6 digits, may include hyphens) | ||
| example: '20-00-00' | ||
| pattern: '^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$' | ||
| description: The UK sort code | ||
| example: '123456' | ||
| minLength: 6 | ||
| maxLength: 6 | ||
| pattern: ^[0-9]{6}$ |
Contributor
There was a problem hiding this comment.
Breaking change: sort code hyphen format removed
The previous pattern '^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$' accepted both hyphenated (20-00-00) and non-hyphenated (200000) sort codes. The new pattern ^[0-9]{6}$ only accepts the 6-digit format without hyphens.
Any existing API consumers who currently provide sort codes in the traditional XX-XX-XX format (which UK banks widely display) will now receive validation errors. If this normalization is intentional, it should be called out explicitly in the description, and consumers should be notified of the format change.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/GbpAccountInfo.yaml
Line: 18-24
Comment:
**Breaking change: sort code hyphen format removed**
The previous pattern `'^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$'` accepted both hyphenated (`20-00-00`) and non-hyphenated (`200000`) sort codes. The new pattern `^[0-9]{6}$` only accepts the 6-digit format without hyphens.
Any existing API consumers who currently provide sort codes in the traditional `XX-XX-XX` format (which UK banks widely display) will now receive validation errors. If this normalization is intentional, it should be called out explicitly in the description, and consumers should be notified of the format change.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+26
to
+32
| description: The type of PIX key | ||
| enum: | ||
| - phone | ||
| - cpf | ||
| - cnpj | ||
| - random |
Contributor
There was a problem hiding this comment.
Potentially breaking: pixKeyType enum uses lowercase values
A new enum constraint has been added to pixKeyType using lowercase values (email, phone, cpf, cnpj, random). If any existing API consumers are passing uppercase or mixed-case values (e.g., EMAIL, CPF, PHONE), they will now fail schema validation. This is a narrowing change on a previously unconstrained string field.
If uppercase or mixed-case variants were previously accepted by the backend, they should be included in the enum, or the description should make the casing requirement explicit.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/BrlAccountInfo.yaml
Line: 26-32
Comment:
**Potentially breaking: `pixKeyType` enum uses lowercase values**
A new `enum` constraint has been added to `pixKeyType` using lowercase values (`email`, `phone`, `cpf`, `cnpj`, `random`). If any existing API consumers are passing uppercase or mixed-case values (e.g., `EMAIL`, `CPF`, `PHONE`), they will now fail schema validation. This is a narrowing change on a previously unconstrained string field.
If uppercase or mixed-case variants were previously accepted by the backend, they should be included in the enum, or the description should make the casing requirement explicit.
How can I resolve this? If you propose a fix, please make it concise.
JasonCWang
approved these changes
Mar 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.