Add USD account bank, account type and wire routing fields - #778
Conversation
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript ✅ grid-ruby studio · code
|
Greptile SummaryAdds optional USD bank-account and wire-routing details, exposes Confidence Score: 5/5The PR appears safe to merge with no actionable defects identified. The optional schema additions are consistently propagated into both generated bundles, reuse established enum and validation contracts, and align with the accompanying documentation without breaking existing required fields.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/common/UsdAccountInfoBase.yaml | Adds five optional, constrained USD account fields with consistent descriptions and examples. |
| openapi/components/schemas/transfers/TransferOutRequest.yaml | Reuses the existing purpose-of-payment enum for an optional transfer-out request field. |
| openapi.yaml | Regenerated bundle accurately reflects the modular schema changes. |
| mintlify/openapi.yaml | Regenerated Mintlify bundle remains synchronized with the root OpenAPI bundle. |
| mintlify/payouts-and-b2b/payment-flow/send-payment.mdx | Documents the optional purpose-of-payment field and its destination-dependent use. |
| mintlify/snippets/external-accounts.mdx | Documents the three wire-specific USD correspondent-bank fields. |
Reviews (1): Last reviewed commit: "Add USD account bank, account type and w..." | Re-trigger Greptile
| maxLength: 140 | ||
| bankAccountType: | ||
| type: string | ||
| description: Whether the account is a checking or a savings account |
There was a problem hiding this comment.
For here and name, we might also want to specify that it's only required for Wires like you do for some of the other fields.
There was a problem hiding this comment.
Good catch — fixed in de71c911, though the answer differs slightly between the two fields, so I documented what's actually true rather than copying the "WIRE rail only" wording across.
Neither bankName nor bankAccountType is wire-only, unlike the three intermediary/FI-to-FI fields:
bankAccountTypematters most on ACH, where checking-vs-savings determines the transaction code. It was previously unexpressible, so the backend hardcodedCHECKINGfor every account.bankNameidentifies the beneficiary's institution on a wire message, but it's equally valid on other rails and no rail requires it.
So both are genuinely optional on every rail, and the descriptions now say that explicitly:
bankName:
description: >-
The name of the financial institution holding the account. Optional on
every rail, and recommended for wires, where it identifies the
beneficiary's institution on the payment message.
bankAccountType:
description: >-
Whether the account is a checking or a savings account. Optional on every
rail; when omitted, the account is treated as a checking account.Also called out the omitted-means-checking default, since that's the existing backend behaviour and worth being explicit about. make lint clean, oasdiff reports 0 breaking changes.
| minLength: 9 | ||
| maxLength: 9 | ||
| pattern: ^[0-9]{9}$ | ||
| bankName: |
There was a problem hiding this comment.
@AaryamanBhute is this file one of the autogenerated ones from your workflow or is USD separate?
There was a problem hiding this comment.
It's autogenerated, I know @JasonCWang and @mohamedwane have been making changes to it though
There was a problem hiding this comment.
On the autogenerated question — the history says it's both, which is worth knowing before this merges.
git log on UsdAccountInfoBase.yaml:
Peter.Rojs Add USD account bank, account type and wire routing fields (this PR)
lightspark-copybara chore: Sync account schemas (#398)
Shreya Vissamsetti Revert "chore: Sync account schemas" (#395)
lightspark-copybara chore: Sync account schemas (#388)
Matt Davis Add bankAccountType to USD, bankName/documentType/documentNumber to COP... (#352)
Aaryaman Bhute Split request and response schemas for external account paymentRails (#302)
So lightspark-copybara[bot] does sync this file, but humans also edit it directly — #352 added bankAccountType to a currency schema by hand, which is exactly the shape of this change. And #395 reverted one of the syncs, so the sync isn't unconditionally authoritative either.
Nothing in this repo generates it locally: no scripts/ entry references it, and make build only bundles openapi/ → openapi.yaml. The one workflow that mentions the directory (docs-sync.yml) just reads these schemas to prompt reviewers about the grid-visualizer.
The practical risk: if a copybara sync runs from a source that doesn't yet have these five properties, it could silently drop them. If that source is upstream of this repo, the fields may need adding there too — otherwise this merges fine and a later sync quietly reverts it. @AaryamanBhute you'd know where that sync originates; happy to mirror the change there if you point me at it.
There was a problem hiding this comment.
Thanks — that's useful, and it flags a real risk I've detailed in the thread above: if the copybara sync originates from a source that lacks these five properties, a later sync would silently drop them.
Two questions where you'd know better than I can infer from history:
- Where does
chore: Sync account schemasoriginate? If these fields also need to exist there, I'm happy to mirror the change so the sync doesn't revert it. - Do the changes @JasonCWang and @mohamedwane have in flight touch
UsdAccountInfoBase? If so, worth sequencing — I'm only adding optional properties (norequiredchanges), so it should merge cleanly either way, but a concurrent sync is the case that would clobber it.
Also worth flagging for whoever merges: this is the spec half only. webdev's generated grid_api client has to be regenerated from the merged spec before the backend can accept these fields — its from_dict whitelists keys, so until then they're silently dropped rather than rejected.
03a91be to
de71c91
Compare
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Merge activity
|
|
📌 Bolt Status 2026-07-31 06:49:29 UTC — ⚡ Agent |
Summary
Adds the USD account fields needed to describe a domestic wire beneficiary, and
purposeOfPaymentonTransferOutRequest.UsdAccountInfoBasecarried onlyaccountNumberandroutingNumber, so a USD account could not express which bank holds it, whether it is checking or savings, or how to reach it through a correspondent. Every other bank-account shape in the spec already has at leastbankName—SwiftAccountInfoBaserequires it, andSlvAccountInfoBasehas bothbankNameandbankAccountTypewith the sameCHECKING/SAVINGSenum reused here.Two of these fields were already documented but never existed in the spec: the "United States" example in
snippets/external-accounts.mdxshowsbankAccountTypeandbankNameon aUSD_ACCOUNT, and the note below it says "Category must beCHECKINGorSAVINGS". This change makes those docs true.Changes
openapi/components/schemas/common/UsdAccountInfoBase.yaml— five optional properties, no change torequired:bankNamebankAccountTypeCHECKING|SAVINGSSlvAccountInfoBase; optional on every rail, defaults to checkingintermediaryBankNameWIRErail onlyintermediaryRoutingNumber^[0-9]{9}$WIRErail onlyfiToFiInformationWIRErail onlyLengths follow the wire-message field sizes: 140 for party name lines, and 210 for the bank-to-bank field (six 35-character lines).
intermediaryRoutingNumbermirrors the existingroutingNumberconstraints exactly.openapi/components/schemas/transfers/TransferOutRequest.yaml— addspurposeOfPayment,$ref-ing the existingquotes/PurposeOfPayment.yaml.QuoteRequestalready accepts it; transfer-out was the only send shape that could not record a payment purpose, even though it accepts the neighbouringremittanceInformation.Also rebundled
openapi.yaml/mintlify/openapi.yamlviamake build, and documented the three wire-only fields pluspurposeOfPaymentin the two affected MDX pages.Compatibility
Additive and non-breaking — every new property is optional and nothing existing changed, so
info.versionis unchanged.Verified against the same gate CI runs:
make lintexits 0 ("Woohoo! Your API description is valid. 🎉"). The remainingschema-properties-have-examples/-descriptionsfindings are pre-existing repo-wide noise; none of them are on the schemas touched here — every property added carries both a description and an example.Test plan
make build— bundle regenerated, diff is additive onlymake lint— exit 0, no findings onUsdAccountInfoBaseorTransferOutRequestoasdiff breaking --fail-on ERR— 0 breaking changesOriginal PR: #765