결함(Bug) #3002
closed[Reservation] Supplier API validation for Gender field
100%
Description
(Impact check on storage, display, and outbound payload when using N/A/None/TBA, etc.)
(1) Request to Dev Team
1. For all suppliers integrated via API, confirm whether the `gender` field is required or not.
2. For suppliers where `gender` is required, check if any supplier has issues when receiving values other than "male" / "female" (e.g., N/A, None, TBA, Unknown).
3. Please share the result as a CSV file including:
- `Supplier ID`, `Supplier name`, `Issue details` (e.g., required/allowed values/invalid cases)
4. Also share: # of suppliers checked / total # of API-integrated suppliers.
(2) Due Date
- This is currently live, so incorrect data may be accumulating in real time.
Please confirm when this validation can be completed (ETA).
Files
Related issues
Updated by Zia Han about 1 month ago
- Related to 결함(Bug) #2922: [Reservation] Gender Default Value Handling added
Updated by Joseph Vo about 1 month ago
- Assignee changed from Joseph Vo to Dan Hoang
Updated by Dan Hoang about 1 month ago
- Status changed from 신규(New) to 진행(Doing)
- Start date set to 02/06/2026
Updated by Dan Hoang about 1 month ago
- File Supplier_API_validation_for_Gender_field.csv Supplier_API_validation_for_Gender_field.csv added
- Due date set to 02/06/2026
- Status changed from 진행(Doing) to 완료(Done)
- % Done changed from 0 to 100
Please refer to Supplier_API_validation_for_Gender_field.csv
Updated by Zia Han 29 days ago
- Status changed from 완료(Done) to 피드백(Feedback)
For context, the policy direction I’m considering is:
Always include the `gender` field in the outbound payload,
but send `null` when the user does not provide gender information.
(Field exists with `null` value, not omitted.)
Based on this assumption, I’d like to confirm the following:
1. Comp Type1 – Vendor(API) classified as 3rd party
Could you please share a CSV file with the following columns for Vendor(API) suppliers?
- Supplier ID
- Supplier Name
- Is gender required? (Yes/No)
- Issue details (constraints, accepted values, special notes)
- Is it safe when gender is `null`? (Yes/No + reason)
2. could you please confirm whether the points discussed in the meeting also apply when gender is `null`?
1) Sanha
- If gender is `null`, is it still automatically converted to `"Mr."`?
- Or is there a different handling logic for empty values?
2) D-Edge
- How is guest title handled when gender is `null`?
- Is this case explicitly defined in the technical documentation?
3) Other Vendor CMS partners (6 vendors)
- Since gender is optional, can you confirm that sending `null` does not cause any integration or processing issues?
4) Non-Vendor CMS Comp Type1 (Dotbiz Extranet, etc.)
- How is gender currently handled?
a. Data storage behavior
b. Extranet UI display wording such as `TBA`
- Would sending `null` also be safe in this flow?
3. Re-send and modification scenarios
- When a booking is created with gender = `null`,are there any cases during:(1)booking updates, (2)re-sending payloads,
where the value is auto-filled or conflicts with existing logic?
4. Logging and monitoring impact
- When gender = `null` is sent:
- Does it trigger any errors, warnings, or validation failures in logs?
- Could this be misinterpreted as an issue from an ops or CS perspective?
Updated by Dan Hoang 14 days ago
Zia Han wrote in #note-5:
It should convert to empty valueFor context, the policy direction I’m considering is:
Always include the `gender` field in the outbound payload,
but send `null` when the user does not provide gender information.
(Field exists with `null` value, not omitted.)Based on this assumption, I’d like to confirm the following:
1. Comp Type1 – Vendor(API) classified as 3rd party
Could you please share a CSV file with the following columns for Vendor(API) suppliers?
- Supplier ID
- Supplier Name
- Is gender required? (Yes/No)
- Issue details (constraints, accepted values, special notes)
- Is it safe when gender is `null`? (Yes/No + reason)2. could you please confirm whether the points discussed in the meeting also apply when gender is `null`?
1) Sanha
- If gender is `null`, is it still automatically converted to `"Mr."`?
- Or is there a different handling logic for empty values?
Handling logic for empty values2) D-Edge
- How is guest title handled when gender is `null`?
Yes, it is optional- Is this case explicitly defined in the technical documentation?
Yes3) Other Vendor CMS partners (6 vendors)
- Since gender is optional, can you confirm that sending `null` does not cause any integration or processing issues?
Empty value4) Non-Vendor CMS Comp Type1 (Dotbiz Extranet, etc.)
- How is gender currently handled?
a. Data storage behavior
Empty valueb. Extranet UI display wording such as `TBA`
Yes- Would sending `null` also be safe in this flow?
Most suppliers support booking modifications, we need handle logic for this. If there are currently no issues related to gender, we do not need to make any changes.3. Re-send and modification scenarios
- When a booking is created with gender = `null`,are there any cases during:(1)booking updates, (2)re-sending payloads,
where the value is auto-filled or conflicts with existing logic?
Currently there are no logs4. Logging and monitoring impact
- When gender = `null` is sent:
- Does it trigger any errors, warnings, or validation failures in logs?
No- Could this be misinterpreted as an issue from an ops or CS perspective?
Updated by Dan Hoang 14 days ago
- File Supplier_3rdParty_API_validation_for_Gender_field.csv Supplier_3rdParty_API_validation_for_Gender_field.csv added
- Due date set to 02/24/2026
- Status changed from 피드백(Feedback) to 완료(Done)
