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?
