chore: Sync account schemas by lightspark-copybara[bot] · Pull Request #384 · lightsparkdev/grid-api

lightspark-copybara · 2026-04-23T18:02:54Z

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 schemas
common/PaymentInstructions.yaml — payment instructions oneOf (new currencies added)
external_accounts/ — per-currency external account schemas (reference common/)

Please review the changes before merging.

vercel · 2026-04-23T18:02:56Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	Apr 23, 2026 6:03pm

github-actions · 2026-04-23T18:03:20Z

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat(types): add bankName to BDT/EGP/GHS/JMD/PKR, add/remove phone fields, update requirements

openapi

feat(types): flatten account schemas, add required fields to USD/BDT/EGP/GHS/GTQ/JMD/PKR accounts

python

feat(api): add bank_name to account types, update payment_rails/beneficiary requirements

typescript

feat(api): add bankName to account types, update USD/COP/GTQ fields, update beneficiary types

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗

✅ grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ❗ → build ✅ → lint ✅ → test ✅

New diagnostics (61 note)

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.

✅ grid-typescript studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ → lint ✅ → test ✅
npm install https://pkg.stainless.com/s/grid-typescript/48cc8b52fac58ddde8c691a64006f2484fa37229/dist.tar.gz

✅ grid-python studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ → lint ✅ → test ✅
pip install https://pkg.stainless.com/s/grid-python/0da228116c78f26ede0542b7d8cee9247ddf8265/grid-0.0.1-py3-none-any.whl

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-04-23 18:08:47 UTC

greptile-apps · 2026-04-23T18:06:11Z

Greptile Summary

This PR auto-syncs 36 *AccountInfo YAML schemas and two beneficiary schemas from sparkcore, replacing allOf/$ref composition with fully self-contained inline definitions and adding per-currency field validation (IBAN patterns, routing numbers, phone formats, etc.).

P1 — USD payment rails: BANK_TRANSFER is removed and MOBILE_MONEY is added. MOBILE_MONEY is an atypical rail for USD; clients that currently submit BANK_TRANSFER for USD payments will fail validation after this change.
P1 — COP/GTQ payment rails: MOBILE_MONEY is removed from both CopAccountInfo and GtqAccountInfo, potentially breaking existing integrations that rely on that rail.
P1 — Beneficiary required fields: CopBeneficiary drops countryOfResidence from required and adds documentNumber/documentType as required; GtqBeneficiary adds phoneNumber as required — both are breaking changes for existing client payloads.

Confidence Score: 3/5

Hold for confirmation — three P1 breaking changes to payment rails and required beneficiary fields need explicit sign-off before merging.

Three distinct P1 findings involve dropped/replaced enum values in payment rails (USD, COP, GTQ) and newly required fields in beneficiary schemas (COP, GTQ) that will break existing client integrations without a migration window. These changes may be intentional syncs from sparkcore, but need explicit confirmation.

UsdAccountInfo.yaml, CopAccountInfo.yaml, GtqAccountInfo.yaml, CopBeneficiary.yaml, GtqBeneficiary.yaml

Important Files Changed

Filename	Overview
openapi/components/schemas/common/UsdAccountInfo.yaml	Refactored from allOf/ref pattern to inline schema; BANK_TRANSFER removed from payment rails and MOBILE_MONEY added — potentially breaking change
openapi/components/schemas/common/CopBeneficiary.yaml	documentNumber and documentType added as required fields while countryOfResidence dropped from required — breaking change for existing COP beneficiary creation
openapi/components/schemas/common/CopAccountInfo.yaml	MOBILE_MONEY removed from COP payment rails enum; schema fully inlined from allOf/ref
openapi/components/schemas/common/GtqAccountInfo.yaml	MOBILE_MONEY removed from GTQ payment rails; schema fully inlined from allOf/ref
openapi/components/schemas/common/GtqBeneficiary.yaml	phoneNumber added as a required field — breaking change for existing GTQ beneficiary creation
openapi/components/schemas/common/PkrAccountInfo.yaml	Schema inlined correctly; iban example uses an incorrect German IBAN placeholder instead of a PK-prefixed example
openapi/components/schemas/common/EgpAccountInfo.yaml	Schema inlined correctly; iban example uses a German IBAN placeholder instead of an EG-prefixed example
openapi/components/schemas/common/DkkAccountInfo.yaml	Schema inlined correctly; iban example uses a German IBAN placeholder instead of a DK-prefixed example
openapi/components/schemas/common/EurAccountInfo.yaml	Cleanly inlined; iban and swiftCode fields added with correct validation patterns and examples
openapi/components/schemas/common/GbpAccountInfo.yaml	Cleanly inlined; sortCode and accountNumber added with correct UK-specific patterns
openapi/components/schemas/common/AedAccountInfo.yaml	Cleanly inlined; iban and swiftCode fields added with UAE-specific pattern and correct examples
openapi/components/schemas/common/BrlAccountInfo.yaml	Cleanly inlined; pixKey, pixKeyType, and taxId fields added with correct Brazilian payment patterns
openapi/components/schemas/common/KesAccountInfo.yaml	Cleanly inlined; Kenya-specific phone pattern and provider field added correctly
openapi.yaml	Bundled OpenAPI spec updated to reflect all schema changes including USD BANK_TRANSFER → MOBILE_MONEY and COP/GTQ payment rail removals
mintlify/openapi.yaml	Mintlify docs bundle mirrors openapi.yaml changes; same P1 concerns apply

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[sparkcore VASP adapter definitions] -->|auto-sync| B[common/ AccountInfo schemas]
    A -->|auto-sync| C[common/ Beneficiary schemas]
    B --> D[external_accounts/ schemas]
    B --> E[openapi.yaml / mintlify/openapi.yaml]
    C --> E

    subgraph Breaking Changes
        F[UsdAccountInfo BANK_TRANSFER removed, MOBILE_MONEY added]
        G[CopAccountInfo and GtqAccountInfo MOBILE_MONEY removed]
        H[CopBeneficiary documentNumber + documentType now required]
        I[GtqBeneficiary phoneNumber now required]
    end

    B --> F
    B --> G
    C --> H
    C --> I

Prompt To Fix All With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/PkrAccountInfo.yaml
Line: 21-28

Comment:
**Incorrect IBAN example for PKR**

The `iban` field uses `DE89370400440532013000` as its example value, which is a well-known German IBAN. Pakistani IBANs start with `PK` followed by 2 check digits, a 4-character bank code, and 16 digits (24 characters total). An example like `PK36SCBL0000001123456702` would be accurate. Using a German example misleads API consumers integrating with PKR accounts.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: PK36SCBL0000001123456702
    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/EgpAccountInfo.yaml
Line: 28-35

Comment:
**Incorrect IBAN example for EGP**

The `iban` field shows `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs follow the format `EG` + 2 check digits + 25 alphanumeric characters (29 chars total). The same German placeholder also appears in `DkkAccountInfo.yaml` (DKK IBANs start with `DK`). Using country-appropriate examples improves clarity for integrators.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: EG800002000156789012345180002
    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/UsdAccountInfo.yaml
Line: 16-23

Comment:
**`BANK_TRANSFER` removed and `MOBILE_MONEY` added to USD payment rails**

The previous schema listed `BANK_TRANSFER` among the allowed USD payment rails; this PR removes it and adds `MOBILE_MONEY` instead. `MOBILE_MONEY` is an unusual rail for USD and could break existing integrations that pass `BANK_TRANSFER` for USD accounts. Is this intentional — i.e., does the USD adapter in sparkcore actually support mobile money but no longer supports generic bank transfer?

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: 3-7

Comment:
**Breaking required-field change in `CopBeneficiary`**

`countryOfResidence` is dropped from `required` and `documentNumber` + `documentType` are added as required. Any existing client that creates a COP beneficiary without providing a document number/type will now receive a validation error. Similarly, `GtqBeneficiary` gains `phoneNumber` as a new required field. If existing integrations are in production, this is a breaking API change that warrants a version bump or a migration window.

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/CopAccountInfo.yaml
Line: 15-18

Comment:
**`MOBILE_MONEY` removed from COP and GTQ payment rails**

Both `CopAccountInfo` and `GtqAccountInfo` previously allowed `MOBILE_MONEY` alongside `BANK_TRANSFER`; the new schemas only list `BANK_TRANSFER`. Clients that currently submit COP or GTQ payments via `MOBILE_MONEY` will fail schema validation after this change. Please confirm whether the corresponding sparkcore adapters have intentionally dropped this rail.

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}

greptile-apps · 2026-04-23T18:06:17Z

+    type: string
+    description: The name of the bank
+    minLength: 1
+    maxLength: 255
+  accountNumber:
+    type: string
+    description: The account number of the bank
+    minLength: 1


Incorrect IBAN example for PKR

The iban field uses DE89370400440532013000 as its example value, which is a well-known German IBAN. Pakistani IBANs start with PK followed by 2 check digits, a 4-character bank code, and 16 digits (24 characters total). An example like PK36SCBL0000001123456702 would be accurate. Using a German example misleads API consumers integrating with PKR accounts.

Suggested change

type: string

description: The name of the bank

minLength: 1

maxLength: 255

accountNumber:

type: string

description: The account number of the bank

minLength: 1

iban:

type: string

description: The IBAN of the bank account

example: PK36SCBL0000001123456702

minLength: 15

maxLength: 34

pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/common/PkrAccountInfo.yaml Line: 21-28 Comment: **Incorrect IBAN example for PKR** The `iban` field uses `DE89370400440532013000` as its example value, which is a well-known German IBAN. Pakistani IBANs start with `PK` followed by 2 check digits, a 4-character bank code, and 16 digits (24 characters total). An example like `PK36SCBL0000001123456702` would be accurate. Using a German example misleads API consumers integrating with PKR accounts. ```suggestion iban: type: string description: The IBAN of the bank account example: PK36SCBL0000001123456702 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.

greptile-apps · 2026-04-23T18:06:18Z

+  iban:
+    type: string
+    description: The IBAN of the bank account
+    example: DE89370400440532013000
+    minLength: 15
+    maxLength: 34
+    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
+  swiftCode:


Incorrect IBAN example for EGP

The iban field shows DE89370400440532013000, which is a German IBAN. Egyptian IBANs follow the format EG + 2 check digits + 25 alphanumeric characters (29 chars total). The same German placeholder also appears in DkkAccountInfo.yaml (DKK IBANs start with DK). Using country-appropriate examples improves clarity for integrators.

Suggested change

iban:

type: string

description: The IBAN of the bank account

example: DE89370400440532013000

minLength: 15

maxLength: 34

pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$

swiftCode:

iban:

type: string

description: The IBAN of the bank account

example: EG800002000156789012345180002

minLength: 15

maxLength: 34

pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/common/EgpAccountInfo.yaml Line: 28-35 Comment: **Incorrect IBAN example for EGP** The `iban` field shows `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs follow the format `EG` + 2 check digits + 25 alphanumeric characters (29 chars total). The same German placeholder also appears in `DkkAccountInfo.yaml` (DKK IBANs start with `DK`). Using country-appropriate examples improves clarity for integrators. ```suggestion iban: type: string description: The IBAN of the bank account example: EG800002000156789012345180002 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.

greptile-apps · 2026-04-23T18:06:20Z

+      type: string
+      enum:
+      - ACH
+      - WIRE
+      - RTP
+      - FEDNOW
+      - MOBILE_MONEY
+  accountNumber:


BANK_TRANSFER removed and MOBILE_MONEY added to USD payment rails

The previous schema listed BANK_TRANSFER among the allowed USD payment rails; this PR removes it and adds MOBILE_MONEY instead. MOBILE_MONEY is an unusual rail for USD and could break existing integrations that pass BANK_TRANSFER for USD accounts. Is this intentional — i.e., does the USD adapter in sparkcore actually support mobile money but no longer supports generic bank transfer?

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/common/UsdAccountInfo.yaml Line: 16-23 Comment: **`BANK_TRANSFER` removed and `MOBILE_MONEY` added to USD payment rails** The previous schema listed `BANK_TRANSFER` among the allowed USD payment rails; this PR removes it and adds `MOBILE_MONEY` instead. `MOBILE_MONEY` is an unusual rail for USD and could break existing integrations that pass `BANK_TRANSFER` for USD accounts. Is this intentional — i.e., does the USD adapter in sparkcore actually support mobile money but no longer supports generic bank transfer? How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-23T18:06:21Z

 required:
 - beneficiaryType
- countryOfResidence
+- documentNumber
+- documentType
 - fullName


Breaking required-field change in CopBeneficiary

countryOfResidence is dropped from required and documentNumber + documentType are added as required. Any existing client that creates a COP beneficiary without providing a document number/type will now receive a validation error. Similarly, GtqBeneficiary gains phoneNumber as a new required field. If existing integrations are in production, this is a breaking API change that warrants a version bump or a migration window.

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/common/CopBeneficiary.yaml Line: 3-7 Comment: **Breaking required-field change in `CopBeneficiary`** `countryOfResidence` is dropped from `required` and `documentNumber` + `documentType` are added as required. Any existing client that creates a COP beneficiary without providing a document number/type will now receive a validation error. Similarly, `GtqBeneficiary` gains `phoneNumber` as a new required field. If existing integrations are in production, this is a breaking API change that warrants a version bump or a migration window. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-23T18:06:22Z

+    items:
+      type: string
+      enum:
+      - BANK_TRANSFER


MOBILE_MONEY removed from COP and GTQ payment rails

Both CopAccountInfo and GtqAccountInfo previously allowed MOBILE_MONEY alongside BANK_TRANSFER; the new schemas only list BANK_TRANSFER. Clients that currently submit COP or GTQ payments via MOBILE_MONEY will fail schema validation after this change. Please confirm whether the corresponding sparkcore adapters have intentionally dropped this rail.

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/common/CopAccountInfo.yaml Line: 15-18 Comment: **`MOBILE_MONEY` removed from COP and GTQ payment rails** Both `CopAccountInfo` and `GtqAccountInfo` previously allowed `MOBILE_MONEY` alongside `BANK_TRANSFER`; the new schemas only list `BANK_TRANSFER`. Clients that currently submit COP or GTQ payments via `MOBILE_MONEY` will fail schema validation after this change. Please confirm whether the corresponding sparkcore adapters have intentionally dropped this rail. How can I resolve this? If you propose a fix, please make it concise.

lightspark-copybara · 2026-04-23T18:48:01Z

Superseded by #385

chore: Sync account schemas

375c1bd

lightspark-copybara Bot mentioned this pull request Apr 23, 2026

chore: Sync account schemas #383

Closed

vercel Bot deployed to Preview April 23, 2026 18:03 View deployment

greptile-apps Bot reviewed Apr 23, 2026

View reviewed changes

lightspark-copybara Bot closed this Apr 23, 2026

lightspark-copybara Bot deleted the auto/sync-grid-schemas-20260423-180252 branch April 23, 2026 18:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore: Sync account schemas - #384

chore: Sync account schemas#384
lightspark-copybara[bot] wants to merge 1 commit into
mainfrom
auto/sync-grid-schemas-20260423-180252

lightspark-copybara Bot commented Apr 23, 2026

Uh oh!

vercel Bot commented Apr 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Apr 23, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Apr 23, 2026

Important Files Changed

Flowchart

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

lightspark-copybara Bot commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

lightspark-copybara Bot commented Apr 23, 2026

Uh oh!

vercel Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✱ Stainless preview builds

Uh oh!

greptile-apps Bot commented Apr 23, 2026

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Flowchart

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

lightspark-copybara Bot commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

vercel Bot commented Apr 23, 2026 •

edited

Loading

github-actions Bot commented Apr 23, 2026 •

edited

Loading