Add USD account bank, account type and wire routing fields - #765
Add USD account bank, account type and wire routing fields#765ls-bolt[bot] wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs.
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|

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|SAVINGSSlvAccountInfoBaseintermediaryBankNameWIRErail 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 changes