Add bankAccountType to USD, bankName/documentType/documentNumber to COP, and COMPANY_LEGAL_NAME field name - #352
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript ✅ grid-python studio · code
✅ grid-typescript studio · code
✅ grid-kotlin studio · code
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThis PR extends the OpenAPI schema with new fields across four components:
Confidence Score: 4/5Safe to merge once the breaking-change implications of the required One P1 concern: adding
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/common/CopAccountInfoBase.yaml | Adds bankName as a required field — a potentially breaking change for existing COP account creation clients; also lacks string length constraints on the new field. |
| openapi/components/schemas/common/CopBeneficiary.yaml | Adds optional documentType and documentNumber fields; documentType is an unconstrained string that would benefit from an enum of valid values. |
| openapi/components/schemas/common/UsdAccountInfoBase.yaml | Adds optional bankAccountType enum (CHECKING/SAVINGS) for corridor-specific requirements; clean change, consistent with COP account pattern. |
| openapi/components/schemas/customers/CustomerInfoFieldName.yaml | Adds COMPANY_LEGAL_NAME to the enum — clean, additive change with no issues. |
| openapi.yaml | Generated bundle reflecting all source schema changes; consistent with component-level edits. |
| mintlify/openapi.yaml | Mintlify-specific generated bundle; identical changes to openapi.yaml, consistent with source changes. |
Entity Relationship Diagram
%%{init: {'theme': 'neutral'}}%%
erDiagram
CopAccountInfoBase {
string accountType "enum: COP_ACCOUNT"
string accountNumber "minLength:1, maxLength:34"
string bankAccountType "enum: CHECKING|SAVINGS"
string bankName "NEW - required"
string phoneNumber "minLength:7, maxLength:15"
}
CopBeneficiary {
string beneficiaryType "enum: INDIVIDUAL"
string fullName
string birthDate
string nationality
string email
string phoneNumber
string countryOfResidence
string documentType "NEW - optional, no enum"
string documentNumber "NEW - optional"
object address
}
UsdAccountInfoBase {
string accountType "enum: USD_ACCOUNT"
string accountNumber "minLength:1, maxLength:34"
string routingNumber "pattern: 9 digits"
string bankAccountType "NEW - optional, enum: CHECKING|SAVINGS"
}
CustomerInfoFieldName {
string enum "...BUSINESS_TYPE"
string COMPANY_LEGAL_NAME "NEW"
}
CopAccountInfoBase ||--o{ CopBeneficiary : "used with"
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 6
Comment:
**Potentially breaking change: `bankName` added as required**
Adding `bankName` to the `required` array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.
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: 30-32
Comment:
**`documentType` should use an enum for valid values**
`documentType` is defined as an unconstrained `string`. Without an enum, any arbitrary value (e.g., `"foobar"`) is schema-valid, which makes interoperability and validation harder. Other document-type fields in payment APIs typically enumerate accepted values. Consider adding an enum of known document types such as `NATIONAL_ID`, `PASSPORT`, `DRIVERS_LICENSE`, etc.
```suggestion
documentType:
type: string
description: The type of identity document
enum:
- NATIONAL_ID
- PASSPORT
- DRIVERS_LICENSE
```
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/CopAccountInfoBase.yaml
Line: 24-26
Comment:
**`bankName` has no string length constraints**
Unlike `accountNumber` (`maxLength: 34`) and `phoneNumber` (`minLength: 7`, `maxLength: 15`), `bankName` has no length bounds. Consider adding `minLength: 1` and a reasonable `maxLength` to prevent empty strings or excessively long values from being submitted.
How can I resolve this? If you propose a fix, please make it concise.Reviews (2): Last reviewed commit: "Add Thunes COP/USD fields for bankName, ..." | Re-trigger Greptile
- COP: Add required bankName to CopAccountInfoBase (AT-4890) - COP: Add documentType/documentNumber to CopBeneficiary (AT-4882) - USD: Add optional bankAccountType to UsdAccountInfoBase for SLV corridor (AT-4884) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@greptile please review |
| - accountType | ||
| - accountNumber | ||
| - bankAccountType | ||
| - bankName |
There was a problem hiding this comment.
bankName added as required
Adding bankName to the required array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 6
Comment:
**Potentially breaking change: `bankName` added as required**
Adding `bankName` to the `required` array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.
How can I resolve this? If you propose a fix, please make it concise.
There was a problem hiding this comment.
this is a clean change, we have no existing Cop accounts
| minLength: 9 | ||
| maxLength: 9 | ||
| pattern: ^[0-9]{9}$ | ||
| bankAccountType: |
There was a problem hiding this comment.
I could have sworn we have this somewhere, so I searched for "CHECKING" in the api and I saw that we only have it (incorrectly) in the example for external account creation as accountCategory. Can you update those examples too for both platform and customer external account creation?
…amples The request examples for both platform and customer external account creation used the incorrect field name `accountCategory`. The actual schema field is `bankAccountType`. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Merge activity
|
TL;DR
Expanded the OpenAPI schema with new fields for COP accounts, USD account info, and customer field definitions.
What changed?
bankNameas a required field toCopAccountInfoBase, capturing the name of the bank for COP accounts.documentTypeanddocumentNumberfields toCopBeneficiary, allowing identity document information (e.g., national ID, passport) to be associated with a beneficiary.bankAccountType(CHECKINGorSAVINGS) toUsdAccountInfoBase, required for certain corridors such as El Salvador.COMPANY_LEGAL_NAMEas a valid enum value toCustomerInfoFieldName, enabling platforms to capture a company's legal name as a customer info field.How to test?
bankNameand that the field is correctly documented in the API reference.documentTypeanddocumentNumbercan be submitted as part of a COP beneficiary payload.bankAccountTypeis accepted and enforced where required.COMPANY_LEGAL_NAMEis accepted as a validCustomerInfoFieldNamevalue in relevant customer info requests.Why make this change?
These additions support expanded corridor requirements and compliance needs. Certain payment corridors (e.g., El Salvador) require bank account type information for USD transfers, COP beneficiaries may need identity document details for regulatory purposes, and
COMPANY_LEGAL_NAMEis needed to capture legal entity information for business customers.