Uh oh!
There was an error while loading. Please reload this page.
chore: Sync account schemas - #388
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript
|
Greptile SummaryThis auto-synced PR updates 42 account schema files, adding schema-level The bulk of the changes (example additions, new
Confidence Score: 4/5Safe to merge if the backend already reflects these breaking changes; needs human confirmation that corridor migrations (especially USD/El Salvador bankAccountType) are handled. Three P1 findings cover breaking schema changes to required fields and enum values across USD, COP, and GTQ schemas. The changes are intentional (generated from sparkcore), but the removal of bankAccountType from UsdAccountInfoBase in particular needs explicit confirmation that no active corridor relies on it. UsdAccountInfoBase.yaml, UsdBeneficiary.yaml, and CopBeneficiary.yaml carry the highest-impact breaking changes and warrant explicit sign-off.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/common/UsdAccountInfoBase.yaml | Removes bankAccountType (CHECKING/SAVINGS) field previously described as required for certain corridors (e.g., El Salvador); adds schema-level example. |
| openapi/components/schemas/common/UsdAccountInfo.yaml | Removes BANK_TRANSFER from the payment method enum — a breaking change for any client currently using that value. |
| openapi/components/schemas/common/UsdBeneficiary.yaml | Adds address, birthDate, and nationality to the required list — breaking change for existing USD beneficiary payloads. |
| openapi/components/schemas/common/CopBeneficiary.yaml | Swaps countryOfResidence out of required in favour of documentNumber and documentType; reorders address and document fields — breaking change for existing integrations. |
| openapi/components/schemas/common/CopAccountInfoBase.yaml | Removes phoneNumber field entirely and reorders required fields; adds bankName with length constraints and a schema-level example. |
| openapi/components/schemas/common/CopAccountInfo.yaml | Removes MOBILE_MONEY from the payment method enum for COP accounts. |
| openapi/components/schemas/common/GtqAccountInfoBase.yaml | Replaces phoneNumber with bankAccountType (CHECKING/SAVINGS enum) and adds required bankName; significantly changes the schema shape for GTQ accounts. |
| openapi/components/schemas/common/GtqAccountInfo.yaml | Removes MOBILE_MONEY from the payment method enum for GTQ accounts, aligned with the GTQ account info restructure. |
| openapi/components/schemas/common/GtqBeneficiary.yaml | Adds phoneNumber to the required list — breaking change for existing GTQ beneficiary payloads that omit phone. |
| openapi/components/schemas/common/EgpAccountInfoBase.yaml | Adds required bankName field; inline IBAN example uses a German IBAN rather than an Egypt-specific one. |
| openapi/components/schemas/common/PkrAccountInfoBase.yaml | Adds required bankName; the optional iban property example uses a German IBAN despite Pakistan not using the IBAN system. |
| openapi.yaml | Generated bundle — reflects all source schema changes; includes the same breaking changes (bankAccountType removal, UsdBeneficiary new required fields, CopBeneficiary required swap, enum removals). |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
subgraph Removed["⛔ Removed / Breaking"]
A["UsdAccountInfoBase\n– bankAccountType field removed\n(was: CHECKING | SAVINGS)"]
B["UsdAccountInfo\n– BANK_TRANSFER enum removed"]
C["CopAccountInfo / GtqAccountInfo\n– MOBILE_MONEY enum removed"]
D["CopAccountInfoBase\n– phoneNumber field removed"]
end
subgraph AddedRequired["⚠️ New Required Fields"]
E["UsdBeneficiary\n+ address, birthDate, nationality"]
F["CopBeneficiary\n+ documentNumber, documentType\n– countryOfResidence (no longer required)"]
G["GtqBeneficiary\n+ phoneNumber"]
H["BDT / EGP / GHS / GTQ / JMD / PKR / COP\n+ bankName (required)"]
end
subgraph AddedOptional["✅ Additive / Examples"]
I["30+ AccountInfoBase schemas\n+ schema-level example block"]
J["GtqAccountInfoBase\nphoneNumber → bankAccountType enum"]
end
Removed --> AddedRequired
AddedRequired --> AddedOptional
Comments Outside Diff (5)
openapi/components/schemas/common/UsdAccountInfoBase.yaml, line 1-27 (link)bankAccountTyperemoved without replacementThe
bankAccountTypefield (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently.Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/UsdAccountInfoBase.yaml Line: 1-27 Comment: **`bankAccountType` removed without replacement** The `bankAccountType` field (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently. How can I resolve this? If you propose a fix, please make it concise.
openapi/components/schemas/common/UsdBeneficiary.yaml, line 1-8 (link)Three new fields added to
requiredaddress,birthDate, andnationalityare now required forUsdBeneficiary. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor.Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/UsdBeneficiary.yaml Line: 1-8 Comment: **Three new fields added to `required`**`address`, `birthDate`, and `nationality` are now required for `UsdBeneficiary`. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor. How can I resolve this? If you propose a fix, please make it concise.
openapi/components/schemas/common/CopBeneficiary.yaml, line 1-7 (link)countryOfResidencedropped,documentNumber/documentTypeaddedcountryOfResidenceis no longer required whiledocumentNumberanddocumentTypeare now mandatory. Existing clients that omit document fields but supplycountryOfResidencewill begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned.Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/CopBeneficiary.yaml Line: 1-7 Comment: **Required fields replaced — `countryOfResidence` dropped, `documentNumber`/`documentType` added**`countryOfResidence` is no longer required while `documentNumber` and `documentType` are now mandatory. Existing clients that omit document fields but supply `countryOfResidence` will begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned. How can I resolve this? If you propose a fix, please make it concise.
openapi/components/schemas/common/EgpAccountInfoBase.yaml, line 21-39 (link)German IBAN used as inline example for an Egyptian account
Both the
ibanproperty-level example (line 24) and the schema-levelexampleblock referenceDE89370400440532013000, which is a German IBAN. Egyptian IBANs begin withEGand are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g.,EG380019000500000000263180002).Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/EgpAccountInfoBase.yaml Line: 21-39 Comment: **German IBAN used as inline example for an Egyptian account** Both the `iban` property-level example (line 24) and the schema-level `example` block reference `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs begin with `EG` and are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g., `EG380019000500000000263180002`). How can I resolve this? If you propose a fix, please make it concise.
openapi/components/schemas/common/PkrAccountInfoBase.yaml, line 22-28 (link)The inline property
exampleforiban(line 25) isDE89370400440532013000, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help.Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/PkrAccountInfoBase.yaml Line: 22-28 Comment: **German IBAN used as example; Pakistan does not use IBAN** The inline property `example` for `iban` (line 25) is `DE89370400440532013000`, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help. How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfoBase.yaml
Line: 1-27
Comment:
**`bankAccountType` removed without replacement**
The `bankAccountType` field (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently.
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/UsdBeneficiary.yaml
Line: 1-8
Comment:
**Three new fields added to `required`**`address`, `birthDate`, and `nationality` are now required for `UsdBeneficiary`. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor.
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/CopBeneficiary.yaml
Line: 1-7
Comment:
**Required fields replaced — `countryOfResidence` dropped, `documentNumber`/`documentType` added**`countryOfResidence` is no longer required while `documentNumber` and `documentType` are now mandatory. Existing clients that omit document fields but supply `countryOfResidence` will begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned.
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/EgpAccountInfoBase.yaml
Line: 21-39
Comment:
**German IBAN used as inline example for an Egyptian account**
Both the `iban` property-level example (line 24) and the schema-level `example` block reference `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs begin with `EG` and are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g., `EG380019000500000000263180002`).
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/PkrAccountInfoBase.yaml
Line: 22-28
Comment:
**German IBAN used as example; Pakistan does not use IBAN**
The inline property `example` for `iban` (line 25) is `DE89370400440532013000`, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help.
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
Uh oh!
There was an error while loading. Please reload this page.
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.