Skip to content

Add COP fields needed for Thunes standard-bank payouts #468

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mohamedwane merged 2 commits into from
May 13, 2026
Merged

Add COP fields needed for Thunes standard-bank payouts #468

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f7639e0
Add COP fields needed for Thunes standard-bank payouts
mohamedwane May 13, 2026
28486db
Address Greptile: enum-constrain documentType, add length guards to d…
mohamedwane May 13, 2026
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
34 changes: 30 additions & 4 deletions mintlify/openapi.yaml
View file
Open in desktop

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

34 changes: 30 additions & 4 deletions openapi.yaml
View file
Open in desktop

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

21 changes: 17 additions & 4 deletions openapi/components/schemas/common/CopAccountInfoBase.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,27 +3,40 @@ required:
- accountType
description: 'Required fields depend on the selected paymentRails:

- BANK_TRANSFER: accountNumber
- BANK_TRANSFER: bankName, accountNumber, bankAccountType

- MOBILE_MONEY: phoneNumber'
properties:
accountType:
type: string
enum:
- COP_ACCOUNT
bankName:
type: string
description: The name of the bank (BANK_TRANSFER only)
minLength: 1
maxLength: 255
accountNumber:
type: string
description: The account number of the bank
description: The account number of the bank (BANK_TRANSFER only)
minLength: 1
maxLength: 34
bankAccountType:
type: string
description: The bank account type (BANK_TRANSFER only)
enum:
- CHECKING
- SAVINGS
phoneNumber:
type: string
description: The phone number in international format
description: The phone number in international format (MOBILE_MONEY only —
Nequi, Daviplata)
example: '+1234567890'
minLength: 7
maxLength: 15
pattern: ^\+[0-9]{6,14}$
example:
accountType: COP_ACCOUNT
bankName: Bancolombia
accountNumber: '1234567890'
phoneNumber: '+1234567890'
bankAccountType: CHECKING
Comment on lines 38 to +42
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot May 13, 2026

Choose a reason for hiding this comment

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

P2 The example was updated to show only BANK_TRANSFER fields and phoneNumber was removed entirely. Because the schema is intentionally a union of both rails (per the PR description), the example now gives no indication of how a MOBILE_MONEY payload looks. Consider splitting into named examples so consumers can see both rail shapes.

Suggested change
example:
accountType: COP_ACCOUNT
bankName: Bancolombia
accountNumber: '1234567890'
phoneNumber: '+1234567890'
bankAccountType: CHECKING
examples:
bankTransfer:
summary: BANK_TRANSFER rail
value:
accountType: COP_ACCOUNT
bankName: Bancolombia
accountNumber: '1234567890'
bankAccountType: CHECKING
mobileMoney:
summary: MOBILE_MONEY rail (Nequi / Daviplata)
value:
accountType: COP_ACCOUNT
phoneNumber: '+573001234567'
Prompt To Fix With AI 
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 38-42

Comment:
The example was updated to show only BANK_TRANSFER fields and `phoneNumber` was removed entirely. Because the schema is intentionally a union of both rails (per the PR description), the example now gives no indication of how a MOBILE_MONEY payload looks. Consider splitting into named `examples` so consumers can see both rail shapes.

```suggestion
examples:
  bankTransfer:
    summary: BANK_TRANSFER rail
    value:
      accountType: COP_ACCOUNT
      bankName: Bancolombia
      accountNumber: '1234567890'
      bankAccountType: CHECKING
  mobileMoney:
    summary: MOBILE_MONEY rail (Nequi / Daviplata)
    value:
      accountType: COP_ACCOUNT
      phoneNumber: '+573001234567'
```

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

Fix in Claude Code

16 changes: 16 additions & 0 deletions openapi/components/schemas/common/CopBeneficiary.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,3 +28,19 @@ properties:
description: The country of residence of the beneficiary
address:
$ref: ./Address.yaml
documentType:
type: string
description: 'Identity document type — required by most Colombian banks.
CC: Cédula de Ciudadanía, CE: Cédula de Extranjería, TI: Tarjeta de
Identidad, NIT: Número de Identificación Tributaria, PP: Passport'
enum:
- CC
- CE
- TI
- NIT
- PP
documentNumber:
type: string
description: Identity document number — required by most Colombian banks
Comment on lines +31 to +44
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot May 13, 2026

Choose a reason for hiding this comment

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

P2 documentType is unconstrained string; documentNumber lacks length guards

The PR description explicitly names the accepted values for documentType (CC, CE, NIT, PP) and maps them to Thunes id_type. Without an enum constraint, any arbitrary string passes schema validation and the error will only surface at the Thunes payer-match step — after the payout has been accepted. Every other typed field in this PR adds stronger validation (bankAccountType gets an enum; bankName and accountNumber get minLength/maxLength). documentNumber similarly lacks minLength: 1, so an empty string is schema-valid even though Thunes would reject it.

If the set of valid documentType values is expected to grow over time (beyond CC/CE/NIT/PP), a comment explaining that is worth adding; otherwise an enum keeps the contract explicit and moves validation to the API boundary.

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

Comment:
**`documentType` is unconstrained string; `documentNumber` lacks length guards**

The PR description explicitly names the accepted values for `documentType` (CC, CE, NIT, PP) and maps them to Thunes `id_type`. Without an `enum` constraint, any arbitrary string passes schema validation and the error will only surface at the Thunes payer-match step — after the payout has been accepted. Every other typed field in this PR adds stronger validation (`bankAccountType` gets an enum; `bankName` and `accountNumber` get `minLength`/`maxLength`). `documentNumber` similarly lacks `minLength: 1`, so an empty string is schema-valid even though Thunes would reject it.

If the set of valid `documentType` values is expected to grow over time (beyond CC/CE/NIT/PP), a comment explaining that is worth adding; otherwise an `enum` keeps the contract explicit and moves validation to the API boundary.

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

Fix in Claude Code

minLength: 1
maxLength: 50
Loading