[kyb] simplify business customer object#287
Merged
wuvictor-95 merged 1 commit intomainfrom Mar 21, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript
|
Contributor
Greptile SummaryThis PR simplifies the business customer schema in two meaningful ways: (1)
Confidence Score: 3/5
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/customers/BusinessInfo.yaml | Replaces $ref enum schemas with inline free-form strings and flattens expectedActivityVolumes; purposeOfAccount and sourceOfFunds examples clearly signal free-form intent, but expectedMonthlyTransaction* examples still use enum-format values creating ambiguity about accepted input. |
| openapi/components/schemas/customers/BusinessInfoUpdate.yaml | Mirror of BusinessInfo.yaml changes for the update path — same enum-to-free-form conversion and flattening of expectedActivityVolumes; carries the same example inconsistency concern. |
| openapi/components/schemas/customers/BusinessCustomerFields.yaml | Removes beneficialOwners from the shared create/update request schema — a breaking change for existing consumers who previously submitted beneficial owner data inline; should be coordinated with a dedicated beneficial-owner endpoint. |
| openapi/components/schemas/customers/BusinessCustomer.yaml | Moves beneficialOwners (as UltimateBeneficialOwner[]) into the read-only response schema; structural change is clean and consistent with the intent to separate ownership management into a dedicated flow. |
| openapi/paths/customers/customers.yaml | Request example updated to use the new flat fields and free-form values; purely cosmetic, consistent with schema changes. |
| openapi.yaml | Generated bundle (via make build); faithfully reflects all component changes — do not edit directly per CLAUDE.md. |
| mintlify/openapi.yaml | Generated Mintlify bundle; mirrors openapi.yaml changes correctly. |
Class Diagram
%%{init: {'theme': 'neutral'}}%%
classDiagram
class BusinessCustomerCreateRequest {
+CustomerCreateRequest
+BusinessCustomerFields
+businessInfo: BusinessInfo
}
class BusinessCustomerUpdateRequest {
+CustomerUpdateRequest
+BusinessCustomerFields
}
class BusinessCustomerFields {
+customerType: BUSINESS
+kybStatus: KybStatus
+address: Address
+businessInfo: BusinessInfoUpdate
-beneficialOwners REMOVED
}
class BusinessCustomer {
+Customer
+BusinessCustomerFields
+businessInfo: BusinessInfo
+beneficialOwners: UltimateBeneficialOwner[] MOVED HERE
}
class BusinessInfo {
+legalName: string
+purposeOfAccount: string (free-form)
+sourceOfFunds: string (free-form)
+expectedMonthlyTransactionCount: string (was nested)
+expectedMonthlyTransactionVolume: string (was nested)
+expectedRecipientJurisdictions: string[]
}
class BusinessInfoUpdate {
+purposeOfAccount: string (free-form)
+sourceOfFunds: string (free-form)
+expectedMonthlyTransactionCount: string (was nested)
+expectedMonthlyTransactionVolume: string (was nested)
}
BusinessCustomerCreateRequest --> BusinessCustomerFields
BusinessCustomerCreateRequest --> BusinessInfo
BusinessCustomerUpdateRequest --> BusinessCustomerFields
BusinessCustomerFields --> BusinessInfoUpdate
BusinessCustomer --> BusinessInfo
BusinessCustomer --> BusinessCustomerFields
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/customers/BusinessInfo.yaml
Line: 50-57
Comment:
**Example values hint at enum intent, but no constraint exists**
`expectedMonthlyTransactionCount` and `expectedMonthlyTransactionVolume` still use enum-format examples (`100_TO_500`, `100K_TO_1M`) — unlike `purposeOfAccount` and `sourceOfFunds`, which were clearly updated to free-form text examples (`"Payout to contractors"`, `"Funds derived from customer payments for software services"`).
This mixed style leaves API consumers uncertain whether these two fields still require an exact bucketed string (like the old enum) or accept arbitrary free-form input. If they still expect only the predefined buckets, the `enum` constraint should be restored:
```yaml
expectedMonthlyTransactionCount:
type: string
description: Expected number of transactions per month
enum:
- LESS_THAN_10
- 10_TO_100
- 100_TO_500
- 500_TO_1000
- MORE_THAN_1000
example: 100_TO_500
expectedMonthlyTransactionVolume:
type: string
description: Expected total transaction volume per month in USD equivalent
enum:
- LESS_THAN_10K
- 10K_TO_100K
- 100K_TO_1M
- 1M_TO_10M
- MORE_THAN_10M
example: 100K_TO_1M
```
If they're truly free-form, the examples should be updated to reflect that (e.g., `"Around 200 per month"`).
The same inconsistency exists in `openapi/components/schemas/customers/BusinessInfoUpdate.yaml` at lines 48–55.
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/customers/BusinessCustomerFields.yaml
Line: 13-14
Comment:
**`beneficialOwners` removed from create/update request — breaking change**
`BusinessCustomerFields` is composed into both `BusinessCustomerCreateRequest` and `BusinessCustomerUpdateRequest`. Removing `beneficialOwners` here means any existing client that currently sends `beneficialOwners` in a create or PATCH request will silently have that data ignored (or receive an unexpected validation error, depending on server-side strictness).
Since there are dedicated `BeneficialOwnerCreateRequest` / `BeneficialOwnerUpdateRequest` schemas in the codebase, it looks like beneficial-owner management is moving to its own endpoint — which is a clean separation. But this is a **breaking change** for the existing contract, and it would be worth:
1. Confirming a corresponding dedicated endpoint for `beneficialOwners` is available (or soon will be), and
2. Adding a deprecation notice or changelog entry so existing integrators know to migrate.
```
(\\_/)
(='.'=) <- this bunny wants a migration guide!
(")_(")
```
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/customers/BusinessInfo.yaml
Line: 42-57
Comment:
**Orphaned component YAML files still present on disk**
`PurposeOfAccount.yaml`, `SourceOfFunds.yaml`, and `ExpectedActivityVolumes.yaml` are still present in `openapi/components/schemas/customers/` but are no longer referenced by `BusinessInfo.yaml` or `BusinessInfoUpdate.yaml` after this PR. They will be silently excluded from the bundled spec (`make build`) but leave dead files in the repo that could confuse future contributors.
Consider deleting them in a follow-up (or as part of this PR):
- `openapi/components/schemas/customers/PurposeOfAccount.yaml`
- `openapi/components/schemas/customers/SourceOfFunds.yaml`
- `openapi/components/schemas/customers/ExpectedActivityVolumes.yaml`
```
(\_/)
( •_•)
/ >🗑️ nom nom orphaned files
```
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: "[kyb] simplify busin..."
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
wuvictor-95
force-pushed
the
03-20-_kyb_simplify_business_customer_object
branch
from
bc57a5d to
cc81d29
Compare
jklein24
approved these changes
Mar 21, 2026
Comment on lines
+50
to
+57
| expectedMonthlyTransactionCount: | ||
| type: string | ||
| description: Expected number of transactions per month | ||
| example: 100_TO_500 | ||
| expectedMonthlyTransactionVolume: | ||
| type: string | ||
| description: Expected total transaction volume per month in USD equivalent | ||
| example: 100K_TO_1M |
Contributor
There was a problem hiding this comment.
expectedMonthlyTransactionCount and expectedMonthlyTransactionVolume still use enum-format examples (100_TO_500, 100K_TO_1M) — unlike purposeOfAccount and sourceOfFunds, which were clearly updated to free-form text examples ("Payout to contractors", "Funds derived from customer payments for software services").
This mixed style leaves API consumers uncertain whether these two fields still require an exact bucketed string (like the old enum) or accept arbitrary free-form input. If they still expect only the predefined buckets, the enum constraint should be restored:
expectedMonthlyTransactionCount:
type: string
description: Expected number of transactions per month
enum:
- LESS_THAN_10
- 10_TO_100
- 100_TO_500
- 500_TO_1000
- MORE_THAN_1000
example: 100_TO_500
expectedMonthlyTransactionVolume:
type: string
description: Expected total transaction volume per month in USD equivalent
enum:
- LESS_THAN_10K
- 10K_TO_100K
- 100K_TO_1M
- 1M_TO_10M
- MORE_THAN_10M
example: 100K_TO_1MIf they're truly free-form, the examples should be updated to reflect that (e.g., "Around 200 per month").
The same inconsistency exists in openapi/components/schemas/customers/BusinessInfoUpdate.yaml at lines 48–55.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/customers/BusinessInfo.yaml
Line: 50-57
Comment:
**Example values hint at enum intent, but no constraint exists**
`expectedMonthlyTransactionCount` and `expectedMonthlyTransactionVolume` still use enum-format examples (`100_TO_500`, `100K_TO_1M`) — unlike `purposeOfAccount` and `sourceOfFunds`, which were clearly updated to free-form text examples (`"Payout to contractors"`, `"Funds derived from customer payments for software services"`).
This mixed style leaves API consumers uncertain whether these two fields still require an exact bucketed string (like the old enum) or accept arbitrary free-form input. If they still expect only the predefined buckets, the `enum` constraint should be restored:
```yaml
expectedMonthlyTransactionCount:
type: string
description: Expected number of transactions per month
enum:
- LESS_THAN_10
- 10_TO_100
- 100_TO_500
- 500_TO_1000
- MORE_THAN_1000
example: 100_TO_500
expectedMonthlyTransactionVolume:
type: string
description: Expected total transaction volume per month in USD equivalent
enum:
- LESS_THAN_10K
- 10K_TO_100K
- 100K_TO_1M
- 1M_TO_10M
- MORE_THAN_10M
example: 100K_TO_1M
```
If they're truly free-form, the examples should be updated to reflect that (e.g., `"Around 200 per month"`).
The same inconsistency exists in `openapi/components/schemas/customers/BusinessInfoUpdate.yaml` at lines 48–55.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
13
to
14
| businessInfo: | ||
| $ref: ./BusinessInfoUpdate.yaml |
Contributor
There was a problem hiding this comment.
beneficialOwners removed from create/update request — breaking change
BusinessCustomerFields is composed into both BusinessCustomerCreateRequest and BusinessCustomerUpdateRequest. Removing beneficialOwners here means any existing client that currently sends beneficialOwners in a create or PATCH request will silently have that data ignored (or receive an unexpected validation error, depending on server-side strictness).
Since there are dedicated BeneficialOwnerCreateRequest / BeneficialOwnerUpdateRequest schemas in the codebase, it looks like beneficial-owner management is moving to its own endpoint — which is a clean separation. But this is a breaking change for the existing contract, and it would be worth:
- Confirming a corresponding dedicated endpoint for
beneficialOwnersis available (or soon will be), and - Adding a deprecation notice or changelog entry so existing integrators know to migrate.
(\\_/)
(='.'=) <- this bunny wants a migration guide!
(")_(")
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/customers/BusinessCustomerFields.yaml
Line: 13-14
Comment:
**`beneficialOwners` removed from create/update request — breaking change**
`BusinessCustomerFields` is composed into both `BusinessCustomerCreateRequest` and `BusinessCustomerUpdateRequest`. Removing `beneficialOwners` here means any existing client that currently sends `beneficialOwners` in a create or PATCH request will silently have that data ignored (or receive an unexpected validation error, depending on server-side strictness).
Since there are dedicated `BeneficialOwnerCreateRequest` / `BeneficialOwnerUpdateRequest` schemas in the codebase, it looks like beneficial-owner management is moving to its own endpoint — which is a clean separation. But this is a **breaking change** for the existing contract, and it would be worth:
1. Confirming a corresponding dedicated endpoint for `beneficialOwners` is available (or soon will be), and
2. Adding a deprecation notice or changelog entry so existing integrators know to migrate.
```
(\\_/)
(='.'=) <- this bunny wants a migration guide!
(")_(")
```
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
42
to
+57
| purposeOfAccount: | ||
| $ref: ./PurposeOfAccount.yaml | ||
| type: string | ||
| description: The intended purpose for using the Grid account | ||
| example: Payout to contractors | ||
| sourceOfFunds: | ||
| $ref: ./SourceOfFunds.yaml | ||
| expectedActivityVolumes: | ||
| $ref: ./ExpectedActivityVolumes.yaml | ||
| type: string | ||
| description: The primary source of funds for the business | ||
| example: Funds derived from customer payments for software services | ||
| expectedMonthlyTransactionCount: | ||
| type: string | ||
| description: Expected number of transactions per month | ||
| example: 100_TO_500 | ||
| expectedMonthlyTransactionVolume: | ||
| type: string | ||
| description: Expected total transaction volume per month in USD equivalent | ||
| example: 100K_TO_1M |
Contributor
There was a problem hiding this comment.
PurposeOfAccount.yaml, SourceOfFunds.yaml, and ExpectedActivityVolumes.yaml are still present in openapi/components/schemas/customers/ but are no longer referenced by BusinessInfo.yaml or BusinessInfoUpdate.yaml after this PR. They will be silently excluded from the bundled spec (make build) but leave dead files in the repo that could confuse future contributors.
Consider deleting them in a follow-up (or as part of this PR):
openapi/components/schemas/customers/PurposeOfAccount.yamlopenapi/components/schemas/customers/SourceOfFunds.yamlopenapi/components/schemas/customers/ExpectedActivityVolumes.yaml
(\_/)
( •_•)
/ >🗑️ nom nom orphaned files
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/customers/BusinessInfo.yaml
Line: 42-57
Comment:
**Orphaned component YAML files still present on disk**
`PurposeOfAccount.yaml`, `SourceOfFunds.yaml`, and `ExpectedActivityVolumes.yaml` are still present in `openapi/components/schemas/customers/` but are no longer referenced by `BusinessInfo.yaml` or `BusinessInfoUpdate.yaml` after this PR. They will be silently excluded from the bundled spec (`make build`) but leave dead files in the repo that could confuse future contributors.
Consider deleting them in a follow-up (or as part of this PR):
- `openapi/components/schemas/customers/PurposeOfAccount.yaml`
- `openapi/components/schemas/customers/SourceOfFunds.yaml`
- `openapi/components/schemas/customers/ExpectedActivityVolumes.yaml`
```
(\_/)
( •_•)
/ >🗑️ nom nom orphaned files
```
How can I resolve this? If you propose a fix, please make it concise.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.