Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 12 additions & 23 deletions mintlify/openapi.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

35 changes: 12 additions & 23 deletions openapi.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

1 change: 1 addition & 0 deletions openapi/components/schemas/common/CopAccountInfo.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -10,3 +10,4 @@ allOf:
type: string
enum:
- BANK_TRANSFER
- MOBILE_MONEY
27 changes: 12 additions & 15 deletions openapi/components/schemas/common/CopAccountInfoBase.yaml
Original file line number Diff line number Diff line change
@@ -1,32 +1,29 @@
type: object
required:
- accountType
- bankName
- accountNumber
- bankAccountType
description: 'Required fields depend on the selected paymentRails:

- BANK_TRANSFER: accountNumber

- MOBILE_MONEY: phoneNumber'
Comment on lines 1 to +8
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Conditional required not enforced at schema level

The description documents that accountNumber is required for BANK_TRANSFER and phoneNumber for MOBILE_MONEY, but neither field appears in the required array — only accountType does. Schema validators (clients, linters, request-validation middleware) will not enforce these conditional requirements. OpenAPI 3.1 supports if/then/else or oneOf discrimination to formally encode this constraint; OpenAPI 3.0 can use oneOf to model the two variants. As-is, missing a required payment-rail-specific field will silently pass schema validation and only fail at runtime.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 1-8

Comment:
**Conditional required not enforced at schema level**

The description documents that `accountNumber` is required for `BANK_TRANSFER` and `phoneNumber` for `MOBILE_MONEY`, but neither field appears in the `required` array — only `accountType` does. Schema validators (clients, linters, request-validation middleware) will not enforce these conditional requirements. OpenAPI 3.1 supports `if/then/else` or `oneOf` discrimination to formally encode this constraint; OpenAPI 3.0 can use `oneOf` to model the two variants. As-is, missing a required payment-rail-specific field will silently pass schema validation and only fail at runtime.

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code

properties:
accountType:
type: string
enum:
- COP_ACCOUNT
bankName:
type: string
description: The name of the bank
minLength: 1
maxLength: 255
accountNumber:
type: string
description: The account number of the bank
minLength: 1
maxLength: 34
bankAccountType:
phoneNumber:
type: string
description: The bank account type
enum:
- CHECKING
- SAVINGS
description: The phone number in international format
example: '+1234567890'
minLength: 7
maxLength: 15
pattern: ^\+[0-9]{6,14}$
example:
accountType: COP_ACCOUNT
bankName: Example Bank
accountNumber: '1234567890'
bankAccountType: CHECKING
phoneNumber: '+1234567890'
Comment on lines 26 to +29
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Misleading example combines mutually exclusive fields

The example object includes both accountNumber and phoneNumber simultaneously, but these fields are mutually exclusive by payment rail (BANK_TRANSFER uses accountNumber, MOBILE_MONEY uses phoneNumber). An API consumer following this example would supply both fields regardless of their chosen payment rail, which is confusing and doesn't model the actual expected usage.

Consider splitting into two separate examples, or picking one canonical example (e.g., the BANK_TRANSFER case).

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 26-29

Comment:
**Misleading example combines mutually exclusive fields**

The `example` object includes both `accountNumber` and `phoneNumber` simultaneously, but these fields are mutually exclusive by payment rail (`BANK_TRANSFER` uses `accountNumber`, `MOBILE_MONEY` uses `phoneNumber`). An API consumer following this example would supply both fields regardless of their chosen payment rail, which is confusing and doesn't model the actual expected usage.

Consider splitting into two separate examples, or picking one canonical example (e.g., the `BANK_TRANSFER` case).

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code

8 changes: 0 additions & 8 deletions openapi/components/schemas/common/CopBeneficiary.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,6 @@ title: Individual Beneficiary
type: object
required:
- beneficiaryType
- documentNumber
- documentType
- fullName
properties:
beneficiaryType:
Expand All @@ -30,9 +28,3 @@ properties:
description: The country of residence of the beneficiary
address:
$ref: ./Address.yaml
documentType:
type: string
description: The type of identity document (e.g., national ID, passport)
documentNumber:
type: string
description: The identity document number
Loading